Get Involved

Overview

There are many ways that you as a member of the community can get involved and contribute to the PDE Project.

The first step is to let us know you are out there, check out the different ways we communicate and chat with us about your problems and interests. You should also sign up for a Bugzilla account and add pde-ui-inbox@eclipse.org and pde-doc-inbox@eclipse.org (or the inbox of the component you are interested in) to your watch list.

Here are some ways you can contribute:

  1. Participate in Bug Day - Some bugs in our inbox are marked with the 'bugday' key word. These are a good place to start contributing as they should require less in-depth knowledge of PDE.
  2. Write code, developing source artifacts and patches for the PDE components.
  3. File bug reports in Bugzilla for defects you find.
  4. Participate in a milestone test pass.
  5. Assist in bug triage by checking if reports are duplicates, out of date, missing fields, etc. Read up on filing bugs and then take a peek at our Inbox.

Communication

The pde-dev mailing list can be used for development discussion and questions about contributing.

We are active on IRC channels #eclipse and #eclipse-dev

PDE has a newsgroup where users can ask for help.

Creating bug reports

If you encounter a bug while working with Eclipse (whether it be with PDE or elsewhere), file a report in bugzilla. However, keep some things in mind:

  • Search bugzilla for existing bugs like yours BEFORE you file it. Resolving duplicates is time consuming.
  • Try to have reproducible steps. An entry in the log file may not be enough. Some log entries are NOT bugs, and can be caused by incorrect workspace configuration, etc.
  • Bugzilla is not a forum. Do not ask questions on bugzilla.
  • New feature requests should be marked with a severity of �enhancement�. Try to give a realistic severity to bugs, a bug with a straightforward workaround is not �critical� or �blocker�.

Bug Lifecycle:

  • NEW - All newly filed bugs start out in the NEW state.
  • DUPLICATE/INVALID/WORKSFORME/WONTFIX - If a bug is a duplicate of another bug or if a committer decides that no code changes will be made for the bug, the bug is resolved immediately with an explanation. Unless the bug is REOPENED for some reason, this is the end of the road.
  • ASSIGNED - If an individual wants to take ownership of a bug (committer or contributor willing to work on it), the bug is reassigned to them, removing it from the inbox. If there is an expected timeframe for the bug to be fixed in, set the target milestone.
  • RESOLVED-FIXED - Bugs are marked as RESOLVED-FIXED once code that solves the issue has been checked into CVS. If a patch was provided by a non-committer it must be marked with the IP Log flag by the committer that committed the code to CVs. Proving a brief explanation of the fix/a list of affected files is recommended.
  • VERIFIED - PDE UI does not explicitly verify bugs. However, if the original reporter or a second committer confirms that a fix does in fact fix the original problem, the bug may be marked as verified.

Setting Up Eclipse

We eat our own dogfood, i.e. we try to use a recent Eclipse build so that we are testing as we work. Updating to the most recent I Build each week is preferred. You can use Update sites to update your current build or download a recent build.

Consider installing and using Mylyn. It can make it easier to switch between tasks. It connects well with Eclipse, PDE and bugzilla.

Eclipse code is written, edited and tested within Eclipse. This is called self-hosting. Here are the basic steps to self host:

  1. Setup the CVS repository: Go to the CVS Repository Exploring Perspective. In the CVS Repositories view you can add the repo by pasting the following (or creating a new connection and filling in the fields in the wizard).
    :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
  2. Look in HEAD for the 'pde' folder. Inside that folder is a project called 'org.eclipse.pde.releng'. Right click and go to Check Out to copy the project to your workspace.
  3. Switch back to the Java perspective, inside the releng project there are a number of .psf files. These project set files can be used to quickly check out the projects you are interested in working on. The pde-ui-basic.psf is where most contributors should start. Simply right click on the file and go to import team project set. A dialog may pop up requiring you to choose a repository to use, as committers must use different settings then contributors.
  4. You can now edit the code in your workspace. To test your code you must create an Eclipse Launch Configuration. The easiest way to do so is to right click on your project, go to Debug As (or Run As) > Run-time Workbench. Your initial Eclipse instance that you edited your code in is called the �host�. The Eclipse you just launched is called the �target�. Any changes you make in your host will be reflected in the target.

Contributing Fixes

In general we follow the standard Eclipse coding style, some things such as indentation, brackets, imports, etc. are enforced by pde project preferences, so your file will be updated when you save.

Try to make your code easily readable adding comments where necessary. Add javadoc (alt-shift-j shortcut) to public methods and classes, even if they are not API.

Once you have created a fix and tested it, you will need it committed to CVS. To do so you must create a patch and attach it to the bug report. A committer will review and commit the fix.

To create a patch, select all of the changed projects in the Package Explorer view. Right click and go to Team > Synchronize, this should open up the Synchronize View. In the Synchronize View, make sure there are no conflicting changes and that all of your changes follow the coding guidelines. Then select your outgoing changes, right click and go to Create Patch... In the dialog, select a destination for the patch (it is best to include the bug number in the file name and use the extension .patch), double check all your changes are included, then hit OK. Attach the created patch to the bug report.

We must follow the Eclipse IP Process. Small contributions will be reviewed and marked with the IP Log flag. Larger contributions will require additional steps.

Some useful links:

Additional Information

If you are interested in helping out, feel free to contact us and ask questions. You can also check out the following resources: