You should send a message to jdt-core-dev@eclipse.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.

You should send a message to jdt-core-dev@eclipse.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.

−

== Coding ==

+

== Coding ==

−

=== Where is the JDT/Core code? ===

+

=== Where is the JDT/Core code? ===

−

All the JDT/Core code is in the Eclipse CVS repository. The JDT/Core projects are:

+

−

* org.eclipse.jdt.compiler.tool

+

−

* org.eclipse.jdt.compiler.tool.tests

+

−

* org.eclipse.jdt.core

+

−

* org.eclipse.jdt.core.tests.builder

+

−

* org.eclipse.jdt.core.tests.compiler

+

−

* org.eclipse.jdt.core.tests.model

+

−

* org.eclipse.jdt.core.tests.performance

+

−

* org.eclipse.test.performance

+

−

=== How do I create a CVS repository connection? ===

+

All the JDT/Core code is in the Eclipse GIT repository. You need to check out the following projects from git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.git

−

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? ===

+

*org.eclipse.jdt.compiler.tool

−

* HEAD: used for the development of the upcoming release. For example, HEAD is currently used for the development of 3.5.

+

*org.eclipse.jdt.compiler.tool.tests

−

* R3_x_maintenance: used for the maintenance of a release. For example, R3_4_maintenance is currently used for the development of 3.4.2.

+

*org.eclipse.jdt.core

+

*org.eclipse.jdt.core.tests.builder

+

*org.eclipse.jdt.core.tests.compiler

+

*org.eclipse.jdt.core.tests.model

+

*org.eclipse.jdt.core.tests.performance

−

=== How should I format my code? ===

+

This project needs to be checked out from git://git.eclipse.org/gitroot/jdt/eclipse.jdt.core.binaries.git

−

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.

+

−

=== What should I do before committing a fix? ===

+

*org.eclipse.jdt.core.tests.binaries

−

* Each fix should have one or more corresponding regression test(s) (except fixes for race conditions, fixes for problems that cannot be reproduced and doc fixes)

+

−

* A CVS patch with the fix and test(s) should be attached to the corresponding bug

+

−

=== What if another committer makes changes in my code? ===

+

This project needs to be checked out from git://git.eclipse.org/gitroot/platform/eclipse.platform.releng.git

−

Each committer is responsible for checking incoming changes in his/her own code. So if another committer makes changes in your code, you should make sure that the change is correct when synchronizing with the CVS repository.

+

−

=== What should I do to backport a fix? ===

+

*org.eclipse.test.performance

−

<p>When a bug is fixed in HEAD, it is sometimes interesting (or necessary) to backport the fix to the maintenance branch. The fix needs first to be modified in order to be applied on top of the maintenance branch's code. It may be easy or tricky depending on how the patch's code area has been touched in the branch.</p>

+

*org.eclipse.test.performance.win32 (if you're on Windows)

−

<p>The bug is either in RESOLVED/FIXED or VERIFIED/FIXED state, which means respectively either in '''State 2''' or in '''State 2.1''' according to the [[#What_is_the_JDT.2FCore_bugs_life_cycle.3F|JDT/Core bug life cycle]].</p>

+

−

<p>So depending of that state, when the fix is ready, you have to:</p>

+

−

# Set the target of the bug and all its duplicates to the corresponding maintenance target (e.g. 3.4.2)

## if the bug is in '''State 2''': "To be verified for <maintenance target>" (e.g. ''To be verified for 3.4.2'')

+

−

## if the bug is in '''State 2.1''': "To be verified for <next milestone>" (e.g. ''To be verified for 3.5M3''). ''Note that in this case, the bug might need to be reopened if the maintenance stream was frozen owing to a service release end of cycle (see [[#What_is_the_JDT.2FCore_bugs_life_cycle.3F|JDT/Core bug life cycle (State 2.2)]].''

+

−

== Committing to CVS ==

+

=== How do I create a Git repository connection? ===

−

=== How do I maintain the build notes? ===

+

Go through http://wiki.eclipse.org/Platform-releng/Git_Workflows to see how to set up Egit and create repository connections. If you're not a committer you should use http instead of ssh, with user id as 'anonymous' and password left blank.

−

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? ===

+

=== What branch should I use? ===

−

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? ===

+

*[http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/?h=master master]: used for the development of the upcoming release. For example, master is currently used for the development of 3.8.

−

<p>Initial answer is: '''NO'''</p>

+

*R3_x_maintenance: used for the maintenance of a release. For example, [http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/?h=R3_7_maintenance R3_7_maintenance] is currently used for the development of 3.7.2.

−

<p>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 [[#What_is_the_verification_process_for_a_milestone.3F|verification process]].</p>

+

−

<p>However, looking at milestone history, re-contributing seldom happened, so <b>if this is really necessary and only for HEAD stream</b>, code releases are allowed if the verification process has well finished and the stream reopened for development.</p>

+

−

<p>See also ''[[#What_should_I_do_if_I_need_to_contribute_after_the_verification_was_finished.3F|What should I do if I need to contribute after the verification was finished?]]'' question...</p>

+

−

=== Can I release code during the build input? ===

+

=== Configuring the workspace ===

−

<p>Again, the answer is: '''NO'''</p>

+

−

<p>The development stream also needs to stay clean during the build input process. It usually starts three hours before the build starts (e.g. 5:00 am - Eastern time) the day of the build input and it ends when "''Released v_XXX for today's build input''" message is sent on jdt-core-dev@eclipse.dev mailing list.</p>

+

Getting the code is the first and the biggest step, but there are a few more steps

−

<p>However, if you have an important fix to release and you're not 100% sure that it will be done before the build input starts (sometimes this happens for European committers...), then just ask to delay it until you're ready. As the process can be shorten a little bit, it is possible to accept <b><u>safe</u></b> contribution until one hour before the build starts... But of course you should not abuse this flexibility. Three hours is the necessary time to run all tests and to have the time to react in case of failures. This is of course not possible when the build input process starts just one hour before!</p>

+

+

*JDT/Core uses project-specific settings for compiler warnings/errors, code formatting etc, which you will automatically get when you clone the Git repository. So you do not have to worry about configuring these.

+

+

*Get a 1.4 JRE or JDK and set it up in the "installed JREs" section in the Eclipse preferences under "Java". You will need this for JDT/Core. You cannot use language features or APIs of java versions greater than 1.4 even while writing your code.

+

+

*For development in the master branch, the '''target platform''' should be the latest 3.8 I-build. By default, the Eclipse SDK will use the Running Platform as the target platform. However you may want to use a different Eclipse version for development, for example some committers use Eclipse 4.x for development. In such a case you should still download the latest 3.8 I-build and use that as the target platform.

+

+

*Enable '''API tooling''', and specify an [[Version Numbering#API_Baseline_in_API_Tools|appropriate API baseline]]. For example, for 3.8 development the baseline should be 3.7.2. Read [http://eclipseandjazz.blogspot.in/2011/10/of-invalid-references-to-system.html Ayushman's blogpost] here for more on this.

+

+

=== 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. Always follow the&nbsp;[http://dev.eclipse.org/conventions.html Eclipse Platform's Standards, Conventions and Guidelines],

+

+

=== Unit Testing ===

+

+

Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to JDT Core. If you are contributing a fix or writing an enhancement, it is a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process.

+

+

There are a few things that you should know about our testing process:

+

+

*Most tests are included in '''org.eclipse.jdt.core.tests.*''' projects.

+

*If you create a new TestCase make sure to add it to the correct test suite.

+

*To launch an existing test, open it in the editor, click on "Run Configurations..." in the coolbar, and create a new "JUnit Plug-in Test". Go to the "Main" tab and choose "Run an application" and select "[No Application - Headless Mode]". Also select the runtime JRE as the latest and greatest version of java that JDT supports. Currently, it is the J2SE 7. Make sure you have a 1.7 JDK with you.

+

*To launch all the JDT/Core tests at once, [http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core.tests.model/src/org/eclipse/jdt/core/tests/RunJDTCoreTests.java org.eclipse.jdt.core.tests.RunJDTCoreTests] should be run.

+

*If you want to make a good impression, write tests. This goes for any project, of course.

+

+

== What should I do before committing a fix? ==

+

+

*Make sure the code is free of errors and also does not introduce any additional warnings. Make sure all tests are green. (This will be done by Hudson once [https://bugs.eclipse.org/bugs/show_bug.cgi?id=385707 bug 385707] is fixed)

+

*Each fix should have one or more corresponding regression test(s) (except fixes for race conditions, fixes for problems that cannot be reproduced and doc fixes).

+

*When ready, prepare to commit to git (Do not 'push' yet). If you're a committer and you want to release your code without a review, you can continue reading these steps , otherwise jump to "Releasing to gerrit code review".

*Make sure the author and committer fields contain correct credentials. If you're releasing a patch for another person, please add their name and email in the "author" field. Click 'Commit'.

+

*Do a 'pull' on the jdt.core git repo so that you have the latest version of the code.

+

*Right-click on the jdt.core repo in the "Git repositories" perspective and click "Push...". Click next after ensuring that the destination git repo is the correct one (ssh://userid@git.eclipse.org:29418/jdt/eclipse.jdt.core.git). In the ref spec setting, choose the current branch you're working on as "source" and in the "destination", type refs/head/master (or refs/head/R3_x_maintenance or refs/head/userid/topicBranch according to where you want to push). Now 'push'.

+

*A Git patch with the fix and test(s) can be optionally attached to the corresponding bugzilla bug for discussion.

+

+

=== Releasing to gerrit code review ===

+

+

1. Choose '''Team > Commit'''... in Egit to open the Commit dialog. In the commit comments, mention the complete bug summary. Eg: "Fixed bug 12345: Eclipse compiler bug". Also select the "Compute change-id for gerrit code review" button on the top right corner of the dialog as shown below. The change-id will be 00... here but as soon as you press the commit button, egit will populate this with a valid change-id. (The change-id makes sure that the patch goes in as a fresh patch set to the existing gerrit review request. For each subsequent patch, you should use the same change-id.)

+

+

[[Image:%247FE9CAF0B8F0829E.png]]

+

+

2. Make sure the author and committer fields contain correct credentials. If you're releasing a patch for another person, please add their name and email in the "author" field. Click 'Commit'.<br>

+

3. Do a 'pull' on the jdt.core git repo so that you have the latest version of the code.<br>

+

4. Right-click on the jdt.core repo in the "Git repositories" perspective and click "Push...". Click next after ensuring that the destination git repo is the correct one (ssh://userid@git.eclipse.org:29418/jdt/eclipse.jdt.core.git). In the ref spec setting, choose the current branch you're working on as "source" and in the "destination", type refs/for/master (or refs/for/R3_x_maintenance or refs/for/userid/topicBranch according to where you want to push). Now 'push'. The result will show a new branch getting created, but in fact the actual result is the patch is pushed to Gerrit!<br>

+

5. Go to the URL https://git.eclipse.org/r/#/. Here you will see the new changes you just pushed. Click on them and mark someone for review. <br>

+

+

''Things to note:''

+

*If you're not a committer, you should ask for your patch to be reviewed by a committer. Additionally, you need to update copyrights on each file you touched as shown below:

+

**The copyright header goes before the package declaration, starting in the very first line.

+

**For new files, list yourself "and others" instead of "IBM and others" in the first line

+

**For each changed file update the copyright year (if required), fill out this template and add it to the header comment:

**If you're a committer releasing a contributor's patch, make sure that the contributor's name and email address is set in the "author" field.

+

+

===Additional steps to take if you're a committer releasing a contributor's patch===

+

If you're a committer reviewing a contributor's patch in gerrit and want to +2 the review, hold on and read the steps below

+

# The contributed patch will have both author and committer fields set to the credentials of the contributor. You need to change the 'committer' field to reflect your credentials.<br>

+

# To do so, please fetch the patch into Eclipse from gerrit (see the section "Fetching a patch from gerrit").<br>

+

# Without changing anything, choose "Team>Commit.." and then click the "Amend commit" button on top right corner of the commit dialog. Now change the 'committer' field to fill in your name and email id "registered with Gerrit" (imp. otherwise push will fail).<br>

+

# Now make sure the change-id is part of the commit message and click commit.<br>

+

# (Optional, but recommended to keep the repo history clean) Rebase on top of origin/master if the change in targetted for master. In case the rebase fails, ask the contributor to do it, no need to waste your time solving conflicts.

# Go to the gerrit link, and mark the patch as +2 for review, and +1 each for verified and ip clean. <br>

+

# Gerrit auto-releases the patch to git. Close the bugzilla bug.<br>

+

+

===Fetching a patch from gerrit===

+

1. To fetch a patch from gerrit into Eclipse, go to the Gerrit URL where the review is requested. Click the patch set you want to fetch. Copy the ref as shown below. This will be the source branch to fetch from Gerrit.

+

+

[[Image:Gerrit-patch-branch.png]]

+

+

2.Now go to "Git Repositories" perspective in Eclipse and right-click on jdt.core repo and choose "Fetch from Gerrit...".

+

3.Paste the path copied in step 1 above in the "Change" as shown below.

+

+

[[Image:Fetch-from-gerrit.png]]

+

+

4. Click Finish and you will have a new branch created with the changes.

+

+

See [[EGit/User_Guide#Fetching_a_change_from_a_Gerrit_Code_Review_Server]] for more info.

+

+

=== What if another committer makes changes in my code? ===

+

+

Each committer is responsible for checking incoming changes in his/her own code. So if another committer makes changes in your code, you should make sure that the change is correct when pulling from the GIT repository.

+

+

=== What should I do to backport a fix? ===

+

+

When a bug is fixed in master, it is sometimes interesting (or necessary) to backport the fix to the maintenance branch. The fix needs first to be modified in order to be applied on top of the maintenance branch's code. It may be easy or tricky depending on how the patch's code area has been touched in the branch.

+

+

The bug is either in RESOLVED/FIXED or VERIFIED/FIXED state, which means respectively either in '''State 2''' or in '''State 2.1''' according to the [[#What_is_the_JDT.2FCore_bugs_life_cycle.3F|JDT/Core bug life cycle]].

+

+

So depending of that state, when the fix is ready, you have to:

+

+

#Set the target of the bug and all its duplicates to the corresponding maintenance target (e.g. 3.4.2)

+

#Release the fix in the maintenance branch (e.g. R3_4_maintenance branch)

+

#Add the corresponding comment (e.g. ''Released for 3.4.2'')

+

#Set the Status Whiteboard to:

+

##if the bug is in '''State 2.1''': "To be verified for &lt;maintenance target&gt;" (e.g. ''To be verified for 3.4.2'')<br>''Note that in this case, the bug might need to be reopened if the maintenance stream was frozen owing to a service release end of cycle (see [[#What_is_the_JDT.2FCore_bugs_life_cycle.3F|JDT/Core bug life cycle (State 2.2)]].''

+

##if the bug is in '''State 2''': "To be verified for &lt;next milestone&gt;" (e.g. ''To be verified for 3.5M3'').<br>''Note that in this case, the bug might not be reopened (typically if the fix is the same than in master branch or released at the same time...)''

+

+

== Releasing to Git ==

+

+

=== How do I maintain the build notes? ===

+

+

Starting from 3.9, an automated e-mail is sent to the release engineering group with the list of projects that have changed and bugs that were fixed for the current build. It's been decided not to maintain a separate build notes for the JDT/Core team. However, should there be a need to make special announcement for a particular build, we can do so by keeping a file namely org.eclipse.jdt.core\buildnotes_jdt-core.html and putting the content in it. When doing so, also make sure that the file is either removed or updated for the subsequent build(s).

+

+

=== What comment should I associate with a commit? ===

+

+

The comment of a commit should be of the form: fixed bug &lt;bug number with summary&gt;, e.g.

+

+

*fixed bug 12345: Eclipse compiler bug

+

*fixed doc for bug 12345

+

+

=== 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 [[#What_is_the_verification_process_for_a_milestone.3F|verification process]].

+

+

However, looking at milestone history, re-contributing seldom happened, so '''if this is really necessary and only for master branch''', 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.3F|What should I do if I need to contribute after the verification was finished?]]'' question...

+

+

=== Can I release code during the build input? ===

+

+

Again, the answer is: '''NO'''

+

+

The development stream also needs to stay clean during the build input process. The build input can start between 1.30 AM EST to 5 AM EST on the day of the build input and it ends when "''Released v_XXX for today's build input''" message is sent on jdt-core-dev@eclipse.dev mailing list.

+

+

It is generally advisable to not release anything on the build input day till the build completes.However, if you have an important fix to release and you're not 100% sure that it will be done before the build input starts , then just ask to delay it until you're ready by sending &nbsp;a note to jdt-core-dev. As the process can be shorten a little bit, it is possible to accept '''<u>safe</u>''' contribution until one hour before the build input starts... But of course you should not abuse this flexibility.<br>

+

+

=== How do I warn users after I changed the build state version or the index file version? ===

−

=== How do I warn users after I changed the build state version or the index file version? ===

Changing the build state version <code>org.eclipse.jdt.internal.core.builder.State#VERSION</code> will cause a full build when the user restarts the workspace with the new version. As well changing the index file version <code>org.eclipse.jdt.internal.core.index.DiskIndex#SIGNATURE</code> will cause all files in the workspace to be reindexed when the user restarts the workspace with the new version. In both case, you should add an entry in the build notes in the "What's new" section so that users are aware of this change.

Changing the build state version <code>org.eclipse.jdt.internal.core.builder.State#VERSION</code> will cause a full build when the user restarts the workspace with the new version. As well changing the index file version <code>org.eclipse.jdt.internal.core.index.DiskIndex#SIGNATURE</code> will cause all files in the workspace to be reindexed when the user restarts the workspace with the new version. In both case, you should add an entry in the build notes in the "What's new" section so that users are aware of this change.

−

* If the build state version is changed, you can add the following entry:

+

*If the build state version is changed, you can add the following entry:

−

<pre>

+

<pre>&lt;li&gt;Fix for &lt;a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=?????"&gt;bug&nbsp;?????&lt;/a&gt; required the build state format to change.

−

<li>Fix for <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=?????">bug ?????</a> required the build state format to change.

+

As a consequence, a full rebuild is expected when reusing existing workspaces.

As a consequence, a full rebuild is expected when reusing existing workspaces.

−

</li>

+

&lt;/li&gt;

−

</pre>

+

</pre>

−

+

*If the index version is changed, you can add the following entry:

−

* If the index version is changed, you can add the following entry:

+

<pre>&lt;li&gt;Fix for &lt;a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=?????"&gt;bug&nbsp;?????&lt;/a&gt; required the index version to be incremented.

−

<pre>

+

−

<li>Fix for <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=?????">bug ?????</a> required the index version to be incremented.

+

Indexes will be automatically regenerated upon subsequent search queries (accounting for indexing notification in search progress

Indexes will be automatically regenerated upon subsequent search queries (accounting for indexing notification in search progress

dialogs).

dialogs).

−

</li>

+

&lt;/li&gt;

−

</pre>

+

</pre>

+

=== What are the rules to release code in the maintenance branch? ===

+

+

You should not start on a fix in maintenance branch (either specific or backport from master) before having got the +1 from the JDT/Core lead added as a comment in the corresponding bug. Then, when the fix is ready, it must be attached to the bug (as usual) and be reviewed by another JDT developer. No code should be released in the maintenance branch without these two conditions verified.

== Bugzilla ==

== Bugzilla ==

=== What is the JDT/Core bugs life cycle? ===

=== What is the JDT/Core bugs life cycle? ===

+

'''Incoming bugs'''

+

* Incoming bugs are triaged by a full-time committer on a rotating basis. The goal is to have an empty inbox, no bug should stay in the inbox for longer than a few days.

+

* As part of the triage, we need to make sure that the bug contains enough information, and that the "severity" is set to a value that makes sense. Enhancement request need to be marked as such, and the same is true for blocker/critical bugs. The bug also needs to be prefixed with the tag [componentArea].

+

* Once the bug is triaged and established as a valid bug, it may not necessarily be assigned to a committer straightaway. If the bug is valid and we feel that we currently do not have enough resources to spend time on that bug, the following is done:

+

# The bug is assigned to the jdt-core-triaged@eclipse.org inbox

+

# The QA contact is set to the committer responsible for fixing bugs in the particular area.

''Note: A bug in the jdt-core-triaged inbox means that it is open to contributions from anyone who wants to take a shot at fixing it. If you want to contribute to such a bug, please leave a comment showing your interest in doing so, or if you're a committer, assign the bug to yourself.''

+

+

+

When a person is '''assigned as the QA contact''' for a bug:

+

* Double-check that there is enough information in the bug, and that the severity is accurate.

+

* If it is a blocker or critical bug (e.g. loss of data, crash), it needs to be fixed as soon as possible. If you are not able to fix the bug yourself, assign it to someone else who is.

+

* If it is a regression, it needs to be fixed during the current development cycle, or potentially in a maintenance stream as well. Schedule the bug accordingly, or assign it to someone else who has time to work on it.

+

* For all other bugs, follow any activity closely and when you are ready to start working on it, assign it to yourself.

+

Here's the diagram for the main states of the JDT/Core bug life cycle:

Here's the diagram for the main states of the JDT/Core bug life cycle:

[[Image:JDTCore_bugs2.jpg]]

[[Image:JDTCore_bugs2.jpg]]

−

Please note the following points which may help to better understand this picture:

+

Please note the following points which may help to better understand the picture shown above:

# not all bug states have been put in this diagram due to an obvious the lack of space. So, the represented states are _only_ those for which committers need to have a peculiar attention and has to apply some rules defined in this FAQ when changing the state of a bug

# not all bug states have been put in this diagram due to an obvious the lack of space. So, the represented states are _only_ those for which committers need to have a peculiar attention and has to apply some rules defined in this FAQ when changing the state of a bug

# some branch may not exist for certain bug. Typically, change the target of a bug to "Y" will not occur when the bug is not backported to another stream than "X". E.g. the left-most branch of this diagram will end at the first "VERIFIED" state for this kind of bug...

# some branch may not exist for certain bug. Typically, change the target of a bug to "Y" will not occur when the bug is not backported to another stream than "X". E.g. the left-most branch of this diagram will end at the first "VERIFIED" state for this kind of bug...

Line 164:

Line 295:

=== What steps should I follow to make a build contribution? ===

=== 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.

+

# Ensure that your local clone for '''org.eclipse.jdt.core''' repository is in sync with the remote.

−

# Close the build notes using the JDT/Core tool (right click on the file, then JDT Core tools > Close build notes).

+

# If you would like to announce something via the build notes, i.e. apart from the bugs that got fixed in this build, you can do so by updating the build notes as mentioned in the build notes section.

−

# Commit the build notes.

+

# For the master branch alone, there is a dedicated '''integration''' branch.

−

# Tag all JDT/Core projects (even those that haven't changed) with the current version (found in the build notes), eg. v_810

+

# Ensure local master is in sync with the remote repository and does not have any local commits or changes.

−

# If needed, check out org.eclipse.releng from the stream you want to contribute to.

# If required, repeat the above steps for the org.eclipse.jdt.core.binariers repository.

−

# Commit org.eclipse.releng/maps/jdtcore.map

+

# For a maintenance stream, since we don't have integration branch, there is no build-input involved. Before the build is started, ensure sync up the stream concerned and ensure that all tests pass. It's possible, but it's been decided not, to have a dedicated integration branch for the maintenance streams as well by specifying/updating the corresponding entry in org.eclipse.releng/tagging/repositories.txt file.

−

# 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 is the milestone verification process? ===

=== What is the milestone verification process? ===

Line 252:

Line 382:

They should test it either as normal development usage or, if some more intensive testing is needed, as described in a specific test plan (e.g. http://www.eclipse.org/jdt/core/r3.3/test-3.3.1.php)

They should test it either as normal development usage or, if some more intensive testing is needed, as described in a specific test plan (e.g. http://www.eclipse.org/jdt/core/r3.3/test-3.3.1.php)

−

=== How do I deliver a patch for a maintenance stream? ===

+

=== How do I deliver a patch for a maintenance stream? ===

−

Note that you should contact Jerome first if you need to deliver a patch for a maintenance stream. In case Jerome is not available, here are the steps to follow:

+

−

# Increment the plugin version id by finding all text references to the previous version id in the org.eclipse.jdt.core project and replacing them with the incremented version id.

+

Note that you should contact the JDT/Core lead first if you need to deliver a patch for a maintenance stream. In case he/she is not available, here are the steps to follow:

−

# Add the following entry to the ''What's new'' section of the build notes:

+

−

#:<pre>&lt;li&gt;Plugin version ID got incremented to [plugin version id].&lt;/li&gt;</pre>

+

#Increment the plugin version id by finding all text references to the previous version id in the org.eclipse.jdt.core project and replacing them with the incremented version id.

−

# Add a reference to the JDT/Core update area for the current stream. E.g. for a patch for 3.0.x, add the following entry to the ''What's new'' section of the build notes:

+

#Add the following entry to the ''What's new'' section of the build notes:

−

#:<pre>&lt;li&gt;Patch available at &lt;a href="http://www.eclipse.org/jdt/core/r3.0/main.html#updates"&gt;http://www.eclipse.org/jdt/core/r3.0/main.html#updates&lt;/a&gt;&lt;/li&gt;</pre>

+

#:<pre>&lt;li&gt;Plugin version ID got incremented to [plugin version id].&lt;/li&gt;</pre>

−

#:Or for a patch for 3.3.x, add the following entry:

+

#Add a reference to the JDT/Core update area for the current stream. E.g. for a patch for 3.0.x, add the following entry to the ''What's new'' section of the build notes:

−

#:<pre>&lt;li&gt;Patch available at &lt;a href="http://www.eclipse.org/jdt/core/r3.3/index.php#UPDATES"&gt;http://www.eclipse.org/jdt/core/r3.3/index.php#UPDATES&lt;/a&gt;&lt;/li&gt;</pre>

+

#:<pre>&lt;li&gt;Patch available at &lt;a href="http://www.eclipse.org/jdt/core/r3.0/main.html#updates"&gt;http://www.eclipse.org/jdt/core/r3.0/main.html#updates&lt;/a&gt;&lt;/li&gt;</pre>

−

# Close the build notes using the JDT/Core tool (right click on the file, then JDT Core tools > Close build notes).

+

#:Or for a patch for 3.3.x, add the following entry:

−

# Add 'Posted on JDT/Core update area' after the date. E.g.

+

#:<pre>&lt;li&gt;Patch available at &lt;a href="http://www.eclipse.org/jdt/core/r3.3/index.php#UPDATES"&gt;http://www.eclipse.org/jdt/core/r3.3/index.php#UPDATES&lt;/a&gt;&lt;/li&gt;</pre>

What branch should I use?

master: used for the development of the upcoming release. For example, master is currently used for the development of 3.8.

R3_x_maintenance: used for the maintenance of a release. For example, R3_7_maintenance is currently used for the development of 3.7.2.

Configuring the workspace

Getting the code is the first and the biggest step, but there are a few more steps

JDT/Core uses project-specific settings for compiler warnings/errors, code formatting etc, which you will automatically get when you clone the Git repository. So you do not have to worry about configuring these.

Get a 1.4 JRE or JDK and set it up in the "installed JREs" section in the Eclipse preferences under "Java". You will need this for JDT/Core. You cannot use language features or APIs of java versions greater than 1.4 even while writing your code.

For development in the master branch, the target platform should be the latest 3.8 I-build. By default, the Eclipse SDK will use the Running Platform as the target platform. However you may want to use a different Eclipse version for development, for example some committers use Eclipse 4.x for development. In such a case you should still download the latest 3.8 I-build and use that as the target platform.

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. Always follow the Eclipse Platform's Standards, Conventions and Guidelines,

Unit Testing

Testing is imperative to the health of the project. We have a significant amount of tests. The quantity of tests will keep growing as more functionality is added to JDT Core. If you are contributing a fix or writing an enhancement, it is a requirement that tests are written. If you don't write them a committer will have to and that could slow down the contribution process.

There are a few things that you should know about our testing process:

Most tests are included in org.eclipse.jdt.core.tests.* projects.

If you create a new TestCase make sure to add it to the correct test suite.

To launch an existing test, open it in the editor, click on "Run Configurations..." in the coolbar, and create a new "JUnit Plug-in Test". Go to the "Main" tab and choose "Run an application" and select "[No Application - Headless Mode]". Also select the runtime JRE as the latest and greatest version of java that JDT supports. Currently, it is the J2SE 7. Make sure you have a 1.7 JDK with you.

If you want to make a good impression, write tests. This goes for any project, of course.

What should I do before committing a fix?

Make sure the code is free of errors and also does not introduce any additional warnings. Make sure all tests are green. (This will be done by Hudson once bug 385707 is fixed)

Each fix should have one or more corresponding regression test(s) (except fixes for race conditions, fixes for problems that cannot be reproduced and doc fixes).

When ready, prepare to commit to git (Do not 'push' yet). If you're a committer and you want to release your code without a review, you can continue reading these steps , otherwise jump to "Releasing to gerrit code review".

Make sure the author and committer fields contain correct credentials. If you're releasing a patch for another person, please add their name and email in the "author" field. Click 'Commit'.

Do a 'pull' on the jdt.core git repo so that you have the latest version of the code.

Right-click on the jdt.core repo in the "Git repositories" perspective and click "Push...". Click next after ensuring that the destination git repo is the correct one (ssh://userid@git.eclipse.org:29418/jdt/eclipse.jdt.core.git). In the ref spec setting, choose the current branch you're working on as "source" and in the "destination", type refs/head/master (or refs/head/R3_x_maintenance or refs/head/userid/topicBranch according to where you want to push). Now 'push'.

A Git patch with the fix and test(s) can be optionally attached to the corresponding bugzilla bug for discussion.

Releasing to gerrit code review

1. Choose Team > Commit... in Egit to open the Commit dialog. In the commit comments, mention the complete bug summary. Eg: "Fixed bug 12345: Eclipse compiler bug". Also select the "Compute change-id for gerrit code review" button on the top right corner of the dialog as shown below. The change-id will be 00... here but as soon as you press the commit button, egit will populate this with a valid change-id. (The change-id makes sure that the patch goes in as a fresh patch set to the existing gerrit review request. For each subsequent patch, you should use the same change-id.)

2. Make sure the author and committer fields contain correct credentials. If you're releasing a patch for another person, please add their name and email in the "author" field. Click 'Commit'.
3. Do a 'pull' on the jdt.core git repo so that you have the latest version of the code.
4. Right-click on the jdt.core repo in the "Git repositories" perspective and click "Push...". Click next after ensuring that the destination git repo is the correct one (ssh://userid@git.eclipse.org:29418/jdt/eclipse.jdt.core.git). In the ref spec setting, choose the current branch you're working on as "source" and in the "destination", type refs/for/master (or refs/for/R3_x_maintenance or refs/for/userid/topicBranch according to where you want to push). Now 'push'. The result will show a new branch getting created, but in fact the actual result is the patch is pushed to Gerrit!
5. Go to the URL https://git.eclipse.org/r/#/. Here you will see the new changes you just pushed. Click on them and mark someone for review.

Things to note:

If you're not a committer, you should ask for your patch to be reviewed by a committer. Additionally, you need to update copyrights on each file you touched as shown below:

The copyright header goes before the package declaration, starting in the very first line.

For new files, list yourself "and others" instead of "IBM and others" in the first line

For each changed file update the copyright year (if required), fill out this template and add it to the header comment:

If you're a committer releasing a contributor's patch, make sure that the contributor's name and email address is set in the "author" field.

Additional steps to take if you're a committer releasing a contributor's patch

If you're a committer reviewing a contributor's patch in gerrit and want to +2 the review, hold on and read the steps below

The contributed patch will have both author and committer fields set to the credentials of the contributor. You need to change the 'committer' field to reflect your credentials.

To do so, please fetch the patch into Eclipse from gerrit (see the section "Fetching a patch from gerrit").

Without changing anything, choose "Team>Commit.." and then click the "Amend commit" button on top right corner of the commit dialog. Now change the 'committer' field to fill in your name and email id "registered with Gerrit" (imp. otherwise push will fail).

Now make sure the change-id is part of the commit message and click commit.

(Optional, but recommended to keep the repo history clean) Rebase on top of origin/master if the change in targetted for master. In case the rebase fails, ask the contributor to do it, no need to waste your time solving conflicts.

Push to refs/for/<destination branch> as instructed in step 4 of "Releasing to gerrit code review" above.

Go to the gerrit link, and mark the patch as +2 for review, and +1 each for verified and ip clean.

Gerrit auto-releases the patch to git. Close the bugzilla bug.

Fetching a patch from gerrit

1. To fetch a patch from gerrit into Eclipse, go to the Gerrit URL where the review is requested. Click the patch set you want to fetch. Copy the ref as shown below. This will be the source branch to fetch from Gerrit.

2.Now go to "Git Repositories" perspective in Eclipse and right-click on jdt.core repo and choose "Fetch from Gerrit...".
3.Paste the path copied in step 1 above in the "Change" as shown below.

4. Click Finish and you will have a new branch created with the changes.

What if another committer makes changes in my code?

Each committer is responsible for checking incoming changes in his/her own code. So if another committer makes changes in your code, you should make sure that the change is correct when pulling from the GIT repository.

What should I do to backport a fix?

When a bug is fixed in master, it is sometimes interesting (or necessary) to backport the fix to the maintenance branch. The fix needs first to be modified in order to be applied on top of the maintenance branch's code. It may be easy or tricky depending on how the patch's code area has been touched in the branch.

The bug is either in RESOLVED/FIXED or VERIFIED/FIXED state, which means respectively either in State 2 or in State 2.1 according to the JDT/Core bug life cycle.

So depending of that state, when the fix is ready, you have to:

Set the target of the bug and all its duplicates to the corresponding maintenance target (e.g. 3.4.2)

Release the fix in the maintenance branch (e.g. R3_4_maintenance branch)

Add the corresponding comment (e.g. Released for 3.4.2)

Set the Status Whiteboard to:

if the bug is in State 2.1: "To be verified for <maintenance target>" (e.g. To be verified for 3.4.2)Note that in this case, the bug might need to be reopened if the maintenance stream was frozen owing to a service release end of cycle (see JDT/Core bug life cycle (State 2.2).

if the bug is in State 2: "To be verified for <next milestone>" (e.g. To be verified for 3.5M3).Note that in this case, the bug might not be reopened (typically if the fix is the same than in master branch or released at the same time...)

Releasing to Git

How do I maintain the build notes?

Starting from 3.9, an automated e-mail is sent to the release engineering group with the list of projects that have changed and bugs that were fixed for the current build. It's been decided not to maintain a separate build notes for the JDT/Core team. However, should there be a need to make special announcement for a particular build, we can do so by keeping a file namely org.eclipse.jdt.core\buildnotes_jdt-core.html and putting the content in it. When doing so, also make sure that the file is either removed or updated for the subsequent build(s).

What comment should I associate with a commit?

The comment of a commit should be of the form: fixed bug <bug number with summary>, e.g.

fixed bug 12345: Eclipse compiler bug

fixed doc for bug 12345

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 master branch, code releases are allowed if the verification process has well finished and the stream reopened for development.

Can I release code during the build input?

Again, the answer is: NO

The development stream also needs to stay clean during the build input process. The build input can start between 1.30 AM EST to 5 AM EST on the day of the build input and it ends when "Released v_XXX for today's build input" message is sent on jdt-core-dev@eclipse.dev mailing list.

It is generally advisable to not release anything on the build input day till the build completes.However, if you have an important fix to release and you're not 100% sure that it will be done before the build input starts , then just ask to delay it until you're ready by sending a note to jdt-core-dev. As the process can be shorten a little bit, it is possible to accept safe contribution until one hour before the build input starts... But of course you should not abuse this flexibility.

How do I warn users after I changed the build state version or the index file version?

Changing the build state version org.eclipse.jdt.internal.core.builder.State#VERSION will cause a full build when the user restarts the workspace with the new version. As well changing the index file version org.eclipse.jdt.internal.core.index.DiskIndex#SIGNATURE will cause all files in the workspace to be reindexed when the user restarts the workspace with the new version. In both case, you should add an entry in the build notes in the "What's new" section so that users are aware of this change.

If the build state version is changed, you can add the following entry:

<li>Fix for <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=?????">bug ?????</a> required the build state format to change.
As a consequence, a full rebuild is expected when reusing existing workspaces.
</li>

If the index version is changed, you can add the following entry:

<li>Fix for <a href="http://bugs.eclipse.org/bugs/show_bug.cgi?id=?????">bug ?????</a> required the index version to be incremented.
Indexes will be automatically regenerated upon subsequent search queries (accounting for indexing notification in search progress
dialogs).
</li>

What are the rules to release code in the maintenance branch?

You should not start on a fix in maintenance branch (either specific or backport from master) before having got the +1 from the JDT/Core lead added as a comment in the corresponding bug. Then, when the fix is ready, it must be attached to the bug (as usual) and be reviewed by another JDT developer. No code should be released in the maintenance branch without these two conditions verified.

Bugzilla

What is the JDT/Core bugs life cycle?

Incoming bugs

Incoming bugs are triaged by a full-time committer on a rotating basis. The goal is to have an empty inbox, no bug should stay in the inbox for longer than a few days.

As part of the triage, we need to make sure that the bug contains enough information, and that the "severity" is set to a value that makes sense. Enhancement request need to be marked as such, and the same is true for blocker/critical bugs. The bug also needs to be prefixed with the tag [componentArea].

Once the bug is triaged and established as a valid bug, it may not necessarily be assigned to a committer straightaway. If the bug is valid and we feel that we currently do not have enough resources to spend time on that bug, the following is done:

The bug is assigned to the jdt-core-triaged@eclipse.org inbox

The QA contact is set to the committer responsible for fixing bugs in the particular area.

Note: A bug in the jdt-core-triaged inbox means that it is open to contributions from anyone who wants to take a shot at fixing it. If you want to contribute to such a bug, please leave a comment showing your interest in doing so, or if you're a committer, assign the bug to yourself.

When a person is assigned as the QA contact for a bug:

Double-check that there is enough information in the bug, and that the severity is accurate.

If it is a blocker or critical bug (e.g. loss of data, crash), it needs to be fixed as soon as possible. If you are not able to fix the bug yourself, assign it to someone else who is.

If it is a regression, it needs to be fixed during the current development cycle, or potentially in a maintenance stream as well. Schedule the bug accordingly, or assign it to someone else who has time to work on it.

For all other bugs, follow any activity closely and when you are ready to start working on it, assign it to yourself.

Here's the diagram for the main states of the JDT/Core bug life cycle:

Please note the following points which may help to better understand the picture shown above:

not all bug states have been put in this diagram due to an obvious the lack of space. So, the represented states are _only_ those for which committers need to have a peculiar attention and has to apply some rules defined in this FAQ when changing the state of a bug

some branch may not exist for certain bug. Typically, change the target of a bug to "Y" will not occur when the bug is not backported to another stream than "X". E.g. the left-most branch of this diagram will end at the first "VERIFIED" state for this kind of bug...

a) if the original bug has not been resolved yet, don't set the milestone on the duplicate (it will be set when the original bug target is set)

b) if the original bug has been resolved:

- use the same milestone on the duplicate as on the original bug

- add the following formatted string to the Status Whiteboard: "To be verified for <next milestone or rollup>" (e.g. To be verified for 3.5M3 or To be verified for 3.4.2)

Note that the next milestone or rollup may be different than the target of the original bug.

Notes - If a bug is backported to a maintenance stream, then see What should I do to backport a fix? question for more details - As soon as you modify the target of a bug, then you have to go through all its duplicates if any and set these duplicates with the same milestone as the one used for the original bug.

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

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, add the following formatted string to the Status Whiteboard: To be verified for <next milestone>, e.g. To be verified for 3.4M6

When can I set a bug to VERIFIED?

The bugs Resolution status is only set to VERIFIED during the verification process the week of the milestone delivery (see How do I verify my bugs?)

Release engineering

What steps should I follow to make a build contribution?

Ensure that your local clone for org.eclipse.jdt.core repository is in sync with the remote.

If you would like to announce something via the build notes, i.e. apart from the bugs that got fixed in this build, you can do so by updating the build notes as mentioned in the build notes section.

For the master branch alone, there is a dedicated integration branch.

Ensure local master is in sync with the remote repository and does not have any local commits or changes.

If required, repeat the above steps for the org.eclipse.jdt.core.binariers repository.

For a maintenance stream, since we don't have integration branch, there is no build-input involved. Before the build is started, ensure sync up the stream concerned and ensure that all tests pass. It's possible, but it's been decided not, to have a dedicated integration branch for the maintenance streams as well by specifying/updating the corresponding entry in org.eclipse.releng/tagging/repositories.txt file.

What is the milestone verification process?

The verification of a milestone is made of two main phases:

bugs verification

build test usage

What is the bugs verification phase?

What are the bugs I have to verify?

All bugs fixed in the milestone's stream must be verified the week of the milestone delivery.
(this is why setting the correct target for bugs is really important - see What target milestone should be used?)

To avoid a bug verifying by several committers at the same time, the whole bugs list is split into several ones.
An email is sent to each verifier with the corresponding list of bugs to verify.

For example, the following bugzilla requests were used to follow the verification progress for milestone 3.4 M2:

How do I verify my bugs?

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 as this bug

DUPLICATE

the problem described in the bug should no longer occur using the build and the bug is really a duplicate of the original

WORKSFORME

the problem described in the bug does not occur using the milestone build

INVALID, NOT_ECLIPSE

the reason why the bug is invalid has to be clearly explained and justified

WONTFIX

the reason why the bug was not fixed has to be clearly explained

Modify the bug according to the result of your verification:

if the verification is OK:

add a formatted comment to the bug: "Verified for <current verified milestone> using <build name> build"

(Note that for build name is not necessary when resolution state is INVALID, NOT_ECLIPSE or WONTFIX).

only if the target of the bug matches the verification process, set the bug Status to VERIFIED

reset the Status Whiteboard contents if it contains the formatted string To be verified for ...

if the verification is KO:

reopen the bug with a comment if 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 scenarios

What if I my fix is not in the build used for the verification?

If your bug fix is not in the build used for the verification (typically if you commit the fix during or after
the verification day), you must coordinate with a verifier and tell him what build to expect the fix in.

When can I consider the verification finished?

When all your bugs are verified, wait for the email sent to all team members and to the jdt-core-dev@eclipse.org list.
This mail describes the status of the verification and indicates which JDT/Core version is eligible for the milestone.
You are also informed whether the corresponding stream is reopened for development or not.

Here's a sample of the email sent at then end of the 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?

Do NOT panic ;-)

The process depends whether the stream was modified since the last version or not:

when no change was done in the stream:

send an email to all committers saying that you need to contribute again

Note: this freezes the milestone stream until the build input's email is sent on jdt-core-dev@eclipse.org

backport the version v_NNN+1 into the buildnotes_jdt-core.html and also into the messages.properties files

What is the build test usage?

When the bugs verification is done and OK, all committers have to use the latest candidate build until the milestone is officially declared.
They should test it either as normal development usage or, if some more intensive testing is needed, as described in a specific test plan (e.g. http://www.eclipse.org/jdt/core/r3.3/test-3.3.1.php)

How do I deliver a patch for a maintenance stream?

Note that you should contact the JDT/Core lead first if you need to deliver a patch for a maintenance stream. In case he/she is not available, here are the steps to follow:

Increment the plugin version id by finding all text references to the previous version id in the org.eclipse.jdt.core project and replacing them with the incremented version id.

Add the following entry to the What's new section of the build notes:

<li>Plugin version ID got incremented to [plugin version id].</li>

Add a reference to the JDT/Core update area for the current stream. E.g. for a patch for 3.0.x, add the following entry to the What's new section of the build notes:

<li>Patch available at <a href="http://www.eclipse.org/jdt/core/r3.0/main.html#updates">http://www.eclipse.org/jdt/core/r3.0/main.html#updates</a></li>

Or for a patch for 3.3.x, add the following entry:

<li>Patch available at <a href="http://www.eclipse.org/jdt/core/r3.3/index.php#UPDATES">http://www.eclipse.org/jdt/core/r3.3/index.php#UPDATES</a></li>

Close the build notes using the JDT/Core tool (right click on the file, then JDT Core tools > Close build notes).

Misc

How do I get the JDT/Core tools?

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.

What about contributions by non-committers?

The Eclipse project uses the Eclipse Foundation's Automatic IP Log system. There are three categories of interesting content for the IP log:

(1) "Small" contributions (patches) coming from non-committers. For this, we ask you to use the attachment flag "iplog+". Please remember to add this flag whenever you commit a patch from a non-committer.

(2) "Large" contributions (code > 250 lines, new feature work) coming from
non-committers. For this, remember that it has to go through the proper IP
review process with the Eclipse Foundation through IPZilla.

(3) Any new, updated (i.e. new versions being used), modified (i.e. we
modify the code) or removed dependencies on third-party code, usually on
bundles that reside in Orbit. This also has to go through the Eclipse
Foundation IP review process.

"Non-committer", in this context, is defined as: anyone who is not a
committer on the Eclipse project (Platform, JDT, PDE) at the time
they make the contribution.