Revision as of 05:08, 16 December 2010

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 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)

(tbd)

Note that the online documentation (User Guide, etc.) are manually checked in to cvs.