Eclipse/Workspace/Committer FAQ

Meta FAQ

Who is this FAQ for?

This FAQ is for the Platform workspace committers, and anyone who is willing to participate in the development of Platform workspace.

What is this FAQ about?

This FAQ is about the rules that Platform/Workspace committers follow when developing the Platform/Workspace component.

How do I contribute to this FAQ?

Simply edit this page. You will need to log in using your bugzilla username and password to gain access. If you don't have a Bugzilla account, you can create a new one.

What should I do after contributing to this FAQ?

For significant changes in development practice, you should send a message to platform-core-dev@eclipse.org with the diff url (e.g. http://wiki.eclipse.org/index.php?title=Eclipse/Workspace/Committer_FAQ&diff=50788&oldid=50780) so that every Platform/Workspace committer is aware of the change.

Coding

Where is the Platform/Workspace code?

All the Platform/Workspace code is in the Eclipse CVS repository. The Platform/Workspace projects are:

• org.eclipse.compare.*
• org.eclipse.core.contenttype
• org.eclipse.core.filesystem
• org.eclipse.core.resources.*
• org.eclipse.team.*

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.5.
• 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.

How should I format my code?

Each project has formatter options in the project-specific settings. So, just hit Ctrl+Shift+F.

What should I do to backport a fix?

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.

• Duplicate the bug, and mark the duplicate with the maintenance branch target milestone</p>
• Release the fix in the maintenance branch, and tag with the org.eclipse.releng project from the same maintenance branch

Committing to CVS

What comment should I associate with a commit?

The comment of a commit should be of the form: <bug number and title> [optional comments]

What else should I do when I commit a change?

When you commit a change, you should:

• Mark the corresponding bug fixed. Trivial changes in HEAD don't need a bug report.
• Ensure the copyright statement is updated based on the source of the contribution. Mark the iplog+ flag in the bug report if applicable
• Run the test suites for the corresponding project (not necessary for trivial changes)

Can I release code during the milestone week?

• Initial answer is: NO
• The milestone stream has to stay clean until the milestone is declared. This enables us to fix a stop ship bug and contribute again without introducing any other changes.
• Once our team has signed off on a milestone candidate, we can reopen the stream for development

Can I release code during the build input?

• Again, the answer is: NO
• The build input is prepared between 6-10 PM EST on Monday prior to the regular Tuesday integration build. Please avoid making contributions during this time.
• If you release a change after this period, you need to perform a separate build contribution for your change.

Bugzilla

What comment should be used when fixing a bug?

Describe the fix that was made and the tests that were written. This is a useful place to record any tricky issues with the fix, since the bug report will be linked to the revision in CVS, and a committer may come back to bugzilla years later to figure out the context for a change. You can also mention what stream the fix is in, although this can be inferred from the target 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 for bugs that have some possibility to be fixed in the future, and WONTFIX for bugs we never intend to fix.

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 INVALID resolution. When a bug is marked INVALID, you should indicate why it is INVALID and what information is missing from the bug.

Misc

How do I get the Core tools?

The core tools bundles have some interesting tools for diagnosing problems and doing performance analysis on the resource tree, listeners, etc. The best way to get the core tools is to check them out from CVS directly, and then build and install them. You need these bundles:

• org.eclipse.core.tools
• org.eclipse.core.tools.resources
• org.eclipse.core.resources.spysupport

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.