Eclipse Project: Releases, Plans, and Reviews

For each release, an Eclipse project is required to provide a project plan. The project plan is created at the beginning of a release cycle and may be modified throughout the cycle. The plan tells the community what the main areas of focus are in the project. This lets, for example, contributors know what kinds of contributions are going to be valuable so they can direct their attention accordingly. It also lets adopters know what to expect from the project for an upcoming release (which may help them to decide to get involved).

At the end of a release cycle, an Eclipse project is required to provide a release review document. For project committers, it serves as a retrospective. It is a chance to look back and reflect on the work done, decide what worked and what didn’t work, and start thinking about the next release cycle. For adopters it is confirmation of the plan and a last chance to update their own plans for how they will incorporate the project code into their own development schedule. For the rest of the community, the review document serves as a description of the changes and a way to learn about what’s new, what’s interesting, and what they should care about.

Our current system keeps track of all this information in a variety of different locations. Project plans are represented as XML files and are stored somewhere within the Eclipse infrastructure (the website, a source repository, or the download site). Basic information about the release, including the name and date is specified in release records in the project metadata in the Eclipse Developer Portal. Release records are relatively limited in terms of the information they can contain; they are restricted to just the basic information, along with links to the project plan, and new and noteworthy documents.

Release review documentation is currently provided in a variety of different formats (e.g. HTML, PDF, PPT, ODP). When a project wants to do a release, they need to tell me. I create a record in the Developer Portal and point that record to the review document that we now store in a corresponding Bugzilla record. Unfortunately, the current system makes no explicit connect connection between the release and the corresponding review document (I’ve added some code that uses some heuristics to figure it out).

Sounds awful. Right?

The new system that Nathan and I are working on brings all these elements together. A project can specify any number of releases, projecting as far as they’d like into the future. The project plan, rather than being in a separately-managed document, is part of the release record. It can be specified at the beginning of a release cycle and updated throughout. The review information is also attached directly to the release record; it too can be updated throughout the release cycle. I think one of the key benefits is that all of the information is kept together in a very consistent form that can be easily organized and disseminated in different ways. Revision management is built in so it’s easy to tell who made changes, compare and revert changes, and so on.

In my opinion, Nathan’s done a great job with the look and feel. Here is what the BIRT project’s 4.2 release looks like:

Note the separate tabs for different elements of the release. Note also that this is just display-only: I don’t have the necessary access to edit this project’s releases. I do, however, have access rights to edit information for the Dash project’s releases:

When editing, separate tabs provide access to the description, plan, and review items. And, again, there’s revision tracking and management.

So the big question: will you use it? Or do we need to provide the ability to attach separate plan and review documents?

I’ll be showing this off at EclipseCon 2012 at a BoF. If you can’t attend the BoF, corner me: I’ll be prepared to demo what we have to anybody wants to see it. We’re going to roll out a version of this that you can play with in the weeks following EclipseCon; with a plan to roll it out as a replacement for the Developer Portal and Data-Driven Project Websites post-Juno (i.e. July 2012).