Virgo/Committers/Process Advice

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 webmaster@eclipse.org. 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 virgo-inbox@eclipse.org to the list of users to watch. gemini.web-inbox@eclipse.org and equinox.framework-inbox@eclipse.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 "virgo-inbox@eclipse.org" 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

(don't)

Creating a release (milestone or higher)

The hardest and riskiest thing to do is run successfully the releaselor script as described here and here.

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:

Repository: :extssh:<commiter_id>@dev.eclipse.org:/cvsroot/org.eclipse

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.