Development advice for committers
These sections are incomplete. Please either supply the required details or request more information if you require it.
ssh keys; why and how to get them
Set up ssh keys so that you are not prompted for a password at many and/or inconvenient points.
- git.eclipse.org - instructions here
- build.eclipse.org - same procedure as for git.eclipse.org
To request a full shell, either raise a bugzilla or email email@example.com. Probably best to email and ask for a full shell on both the above servers.
how to subscribe to virgo-inbox
You need to do this so you are notified of new bugs.
- Open bugzilla in a browser.
- Click on Preferences.
- Click on the Email Preferences tab.
- Add firstname.lastname@example.org to the list of users to watch. email@example.com and firstname.lastname@example.org may also be of interest.
how to fix a bug
All our enhancements and bugs (in fact, every change that happens to the product or the code base) start life with a bugzilla. We generically refer to them all as bugs. Bugzilla entries should record any information associated with the change.
To make it easier to share the work it is helpful to follow some simple guidelines:
- starting work on a bug
- assign it to yourself while you are working on it: change the "Assigned to" field to contain your email address and change the status to ASSIGNED.
- if you make a code change for the bug, ensure the commit log message begins with "bug nnnnnn: "
- giving up on a bug
- if you want to pass the bug to someone else to work on, please change the "Assigned to" field.
- if you want to put the bug back in the backlog, please change the "Assigned to" field to "email@example.com" and change the status to NEW.
- closing a bug
- If you want to remember to make sure the raiser validates the fix, change the status to RESOLVED and let the raiser change it to CLOSED.
- if the fix is straightforward and you don't want to involve the raiser, change the status to CLOSED.
what is a ripple and when to do one
Creating a release (milestone or higher)
What remains if everything goes well is to update the online documentation (User guide, etc.) and the relevant web pages of the Virgo project.
Both are manually checked in to CVS.
CVS settings are as follows:
Path: HEAD/www/virgo/documentation and HEAD/www/virgo/download
Here's a list of simple steps after the CVS access is configured:
1. Delete the current documentation from HEAD/www/virgo/documentation/version/docs/*
2. Upload on the same location the new documentation that was produced by the releaselor script in its working directory
3. Move the index.php file from HEAD/www/virgo/documentation/old_version to the new version folder you just created for the new release and change the links inside it to match the new version.
4. Create new release notes for the new version and upload them in HEAD/www/virgo/download/release-notes. Follow the naming standard of the existing release notes there.
5. Change index.php or milestones.php in HEAD/www/virgo/download depending on what release you are producing to include the new version on the download page.
Creating Tomcat binaries as bundles
Tomcat binaries do not provide OSGi metadata, so we use bundlor in order to make them bundles.
Tomcat binaries and sources can be obtained from the maven repository: http://repo2.maven.org/maven2/org/apache/tomcat/
For Tomcat 7.0.12 we use the following 9 jar files :