Nathan and I have been working on a new Project Management Infrastructure for the Eclipse Foundation. Some think of it as a replacement for the current Developer Portal. I see it as more than that. There are many aspects of project management at Eclipse that just aren’t covered by the existing portal.
Releases have been driving me crazy for a long time. My biggest issue with releases is all the different pieces of information that are required, and all the different mechanisms for capturing and disseminating those various bits of information.
Minimally, a release requires name and date. This information is captured in the current developer portal.
Projects are required to have a project plan (in the standard format) in order to make a release. The project plan captures lots of information, including a overview of the release, description of the deliverables, list of milestones, a handful of themes, and about a half dozen of other optional fields. The plan itself is represented in XML and stored on an eclipse.org property (generally the project website).
In general, the release and project plan are specified relatively early in a development cycle and evolve as development occurs.
At the end of the development cycle–before a project can be released–still more information needs to be provided in the form of a release review. The review is partially a retrospective that projects can use to reflect on the progress made, identify mistakes, and improve the process for the next cycle. It’s also used to inform the community of the progress made. Though, I tend to think of the review part as being a little too late in the cycle for adopters: adopters probably should be paying attention during the planning stage. Still, as a retrospective and record of the release, I believe that the review is important.
This is a bit of a rehash; I’ve talked about all this before.
In Bug 363524, I started detailing a plan to roll releases, plans, and reviews together. My thinking is to roll all the different pieces of information into a single location, remove the redundancy, and make it dirt-easy to enter and maintain. Heck, why not put it into a database in a form that we can actually use for more than just displaying a static document? That sounds like crazy talk.
We’ve implemented the first cut of this.
With this screenshot, I’m showing the EclipseLink project’s 2.0.0 release. We’ve implemented some scripts that mine the information from the existing databases and project plan documents an import it into a “release” record. That single record holds all the information, and can stand as the review document and the project plan in one (we can generate the project plan in the standard XML format if necessary). A summary of the release (including a subset of the information) is displayed on the project page.
A project member can edit the release with the click of a button.
Putting this together exposed a disturbing detail: releases potentially contain a huge amount of information:
- Release name (e.g. “1.0”);
- Release date;
- Link to approved IP Log;
- Link to the New and Noteworthy;
- Rich text description of the release (i.e. release goals, features included in the release, that sort of thing);
- Rich text discussion of non-code aspects;
- Rich text discussion of architectural issues;
- Rich text summary of usability issues;
- Rich text discussion of end-of-life issues/features;
- Bugzilla product/components/milestones included in this release;
- Rich text discussion of standard compliance;
- Rich text discussion of community development activities undertaken during release cycle;
- A collection of “themes” for the release (e.g. ‘Design for Extensibility”) with optional rich text description;
- A list of milestones; each including a name (e.g. “m1”), date, optional description;
- Rich text field for “other information”;
- Checkbox certification that the release’s APIs are of “Eclipse Quality”;
- Checkbox certification that security issues have been reviewed;
- Checkbox certification that the Eclipse IP Policy has been followed;
- A further field for feedback from the PMC/EMO.
I think we can do better than this. Many of these fields are optional, but the presentation of all of them is daunting. Perhaps some of the optional fields can be re-positioned as themes. I’m not sure what the right answer is right now (keep in mind that nothing in this list is a new requirement; in fact, this list is actually shorter that what is required for a release today). Your input is welcome on Bug 363524. It’s still early days, but I do plan to make our implementation accessible soon so that we can get some real feedback.
We’ve only just started working on the theming of the output. I’m pretty excited about the look Nathan has developed and am looking forward to rolling it out tomorrow or early next week. I’ll show that off when it’s a little more baked.
