JDT Core Committer FAQ
- 1 Meta FAQ
- 2 Coding
- 3 Committing to CVS
- 4 Bugzilla
- 4.1 What bugs are currently opened against JDT/Core?
- 4.2 What target milestone should be used?
- 4.3 What comment should be used when fixing a bug ?
- 4.4 The resolution LATER is deprecated. What should I use instead ?
- 4.5 The resolution REMIND is deprecated. What should I use instead?
- 4.6 What status/resolution should I use after marking a bug duplicate?
- 4.7 When can I set a bug to VERIFIED?
- 5 Release engineering
- 5.1 What steps should I follow to make a build contribution ?
- 5.2 What bugs needs to be verified before a milestone delivery?
- 6 Misc
- 7 Links
Who is this FAQ for ?
This FAQ is for the JDT/Core committers, and anyone who is willing to participate in the development of JDT/Core.
What is this FAQ about ?
This FAQ is about the rules that JDT/Core committers follow when developing the JDT/Core component.
How do I contribute to this FAQ ?
What should I do after contributing to this FAQ ?
You should send a message to firstname.lastname@example.org with the diff url (e.g. http://wiki.eclipse.org/index.php?title=JDT_Core_Committer_FAQ&diff=50788&oldid=50780) so that every JDT/Core committer is aware of the change.
Where is the JDT/Core code ?
All the JDT/Core code is in the Eclipse CVS repository. The JDT/Core projects are:
How do I create a CVS repository connection ?
The following information must be used to create a CVS repository connection:
- Connection type: extssh (or pserver if you are not yet a committer and don't have an Eclipse account)
- User: <your id> (or anonymous if you are not yet a committer and don't have an Eclipse account)
- Password: <your password>
- Host: dev.eclipse.org
- Repository path: /cvsroot/eclipse
- Use default port
What branch should I use ?
- HEAD: used for the development of the upcoming release. For example, HEAD is currently used for the development of 3.4.
- R3_x_maintenance: used for the maintenance of a release. For example, R3_3_maintenance is currently used for the development of 3.3.1.
How should I format my code ?
We currently don't have a formatter profile available. But the rule is that you should try to format your code as the surrounding code. If you are not sure, use the Eclipse [built-in] formatter profile which is very close to the JDT/Core team's formatting style.
Committing to CVS
How do I maintain the build notes ?
The build notes (in org.eclipse.jdt.core/buildnotes_jdt-core.html) should be updated just before committing a bug fix. This file should be committed at the same time as the bug fix. To update the build notes, use the JDT/Core tool (right click on the file, then JDT Core tools > Add to build note...).
What comment should I associate with a commit ?
The comment of a commit should be of the form: <branch> - <bug number with optional comments>, e.g.
- HEAD - 1234567
- R3_3_maintenance - fix for 123678 (with tests)
Can I release code during the milestone week?
Initial answer is: NO
The milestone stream has to stay clean until the milestone is declared. Then, we would be able to fix a stop shipping bug and contribute again without introducing any other changes since the verification process.
However, looking at milestone history, re-contributing seldom happened, so if this is really necessary and only for HEAD stream, code releases are allowed if the verification process has well finished and the stream reopened for development.
See also What should I do if I need to contribute after the verification was finished? question...
What bugs are currently opened against JDT/Core?
What target milestone should be used?
- If the bug is marked as WORKSFORME
- a) if you tested the problem with a pure milestone build, use this milestone (e.g. if you've tested that a problem works with a pure 3.4M1 build, then use 3.4M1)
- b) if you tested the problem with an integration build, use the next milestone (e.g. if you've tested that a problem works with an integration build after 3.4M1, then use 3.4M2)
- If the bug is marked as DUPLICATE,
- a) if the original bug has not been fixed yet, don't set the milestone on the duplicate (it will be set when rule 6 is applied)
- b) if the original bug has been fixed, use either rule 1a. or rule 1b.
- c) if the original bug has been set to WONTFIX or INVALID, use next milestone (rule 3).
- If the bug is marked WONTFIX or INVALID, use the next milestone (in this case, the target is simply used to identify that the bug has been closed during this specific period...)
- If the bug is marked FIXED, use the next milestone (as we always do)
- If a bug is backported to a maintenance stream, change the target milestone to the next maintenance release (e.g. if a bug fixed in 3.4M1 is backported to R3_3_maintenance, then change the milestone to 3.3.1)
- In all cases, go through the duplicates of the bug being resolved, and set these duplicates with the same milestone as the one used for the bug being resolved
What comment should be used when fixing a bug ?
When changing a bug to RESOLVED/FIXED a comment containing the following string should be use: "released for <target milestone | maintenance release>". E.g.
- Fixed and released for 3.4M2 in HEAD
- Released for 3.3.1
This string is used when querying the bugs to verify for a particular milestone.
The resolution LATER is deprecated. What should I use instead ?
Bugs that we don't plan to fix used to be resolved as LATER. Since this resolution is deprecated, we shall now use the P5 priority.
The resolution REMIND is deprecated. What should I use instead?
Bugs that needed more information used to be resolved as REMIND. Since this resolution is deprecated, we shall now use the needinfo keyword.
What status/resolution should I use after marking a bug duplicate?
- If the original bug is marked RESOLVED/FIXED, leave it to RESOLVED/DUPLICATE
- If the original bug is marked VERIFIED/FIXED, change it to VERIFIED/DUPLICATE
When can I set a bug to VERIFIED?
Bugs Resolution status is only set to VERIFIED during the verification process the week before milestone delivery (see How should I process to verify milestone bugs?)
What steps should I follow to make a build contribution ?
- Ensure that you are in sync with the stream (HEAD, R3_x_maintenance, ...) you want to contribute to.
- Close the build notes using the JDT/Core tool (right click on the file, then JDT Core tools > Close build notes).
- Commit the build notes.
- Tag all JDT/Core projects (even those that haven't changed) with the current version (found in the build notes), eg. v_810
- If needed, check out org.eclipse.releng from the stream you want to contribute to.
- Edit org.eclipse.releng/maps/jdtcore.map:
- Change the contribution date
- Change all version numbers to the new one
- Commit org.eclipse.releng/maps/jdtcore.map
- Send a message to the jdt-core-dev mailing list saying that the contribution was made including the version number, e.g. a message with the following title: "Released v_810 for today's integration build" and no body is sufficient.
What bugs needs to be verified before a milestone delivery?
How should I process to verify milestone bugs?
All bugs which fixes were released in milestone corresponding stream must be verified the week before milestone delivery. This is why setting the correct target for bugs is really important (see What target milestone should be used? question).
Usually this verification starts as soon as a warm-up build is available on Eclipse Project Downloads page and is done by several JDT/Core committers.
The corresponding stream is frozen (i.e. no code shall be released in it) during this verification.
To avoid that a bug was verified by several committers at the same time, the whole bugs list is split in several ones and dispatched onto all verifiers. Corresponding bugzilla requests are used to follow-up work in progress during the verification:
The verifier goes through his list and verifies that the resolution state of each bug in the list is correct:
- the problem described in the bug should no longer occur using the milestone build
- all duplicate bugs (if any) have to have the same target than this bug
- the problem described in the bug should no longer occur using the build and the bug is really a duplicate of the original
- the problem described in the bug still does not occur using the milestone build
- the reason why the bug was not fixed has to be clearly explained
Depending on the result of the verification, the verifier has to:
- if the verification is OK:
- set the bug Resolution to VERIFIED if the target matches the current verified milestone
- set Status Whiteboard to the formatted string: Verified for <current verified milestone> if the bug's target matches another milestone
- if the verification is KO:
- reopen the bug if it's the described scenario is not fixed
- open a new bug if a part of the problem is solved but there are still remaining issues using different scenarii
When can I consider the verification finished?
When all bugs are verified, a mail is sent to all committers team members and on email@example.com list. This mail describes the global result of the verification and indicates which JDT/Core version is eligible for the milestone. Team members are also informed whether the corresponding stream is reopened for development or not.
Here's a sample of the mail sent at then end of 3.4M2 verification
- Version v_813 of org.eclipse.jdt.core project should be the JDT/Core contribution for 3.4 M2 milestone...
- So you can consider JDT/Core projects HEAD reopened for development :-)
What should I do if I need to contribute after the verification was finished?
First do NOT panic ;-)
How do I get the JDT/Core tools ?
The JDT/Core tool can be obtained from this update site: http://www.eclipse.org/jdt/core/tools/jdtcoretools/update-site/ using Eclipse update manager.
An integration or maintenance build is red. Should I take it ?
A red build doesn't mean that it is not usable. It just means that some tests failed. The impact of failing tests is often negligeable. E.g. if the releng tests are failing, it just means that there is a problem in the Javadoc. So you should always take the latest integration or maintenance build, unless someone posted on the platform-releng-dev mailing list that it is not usable.