Revising Eclipse Development Process: Release Reviews

I made a mention to Mike a couple of weeks back that I wanted to make a few changes to the Eclipse Development Process (EDP). He seemed to think that evolving our process was a grand idea and reminded me that changes to the development process require approval from the Eclipse Board. I knew that already, but it was still nice of him to remind me (he’s one of those give-you-gentle-reminders-and-let-you-get-it-done sorts of bosses). But I digress.

I was originally thinking of only a few small changes. But I’ve gathered up a bit of steam and have decided that maybe it’s worth trying to make some more fundamental changes. I’ve been in this role for about nine months; after nine months of immersion in our process, I have some ideas where I think we can do a better job. But before I start making wholesale changes, I though it might be prudent to try and bring some of my ideas before the community to gather feedback. Keep in mind that–ultimately–any changes we make to the development process do have to be approved by the board, are bounded by our bylaws, etc.

There are several key principles that I believe underly the EDP (in no particular order, because they’re all important):

  • Transparency
  • Openness
  • IP cleanliness
  • Quality

I believe that most of what we find in the EDP is intended to support one of these key principles. Correct me if I’m wrong.

There’s one more thing that I’ve added to this list:

  • “Do the right thing” ahead of process.

Recently, I’ve been thinking a heck of a lot about reviews. Release reviews in particular. I’ve had many conversations with committers about release reviews and why we do them. Years ago, we required that project members “meet” the community on a scheduled call to present their case for release. Attendance on those calls was never particularly strong, and so the call melted away and we’ve effectively changed over to a “review period” of a week that infrequently involves some kind of call. The project still has to provide review “docuware” and the working theory is that interested parties from the community read this carefully prepared documentation and then theoretically pose questions that are theoretically answered. I don’t mean to sound overly theoretical, but my experience is that most of these documents are read by Anne and me, and few others outside of the project. Correct me if I’m wrong.

I’ve written in the past about how valuable I think these documents are. This hasn’t changed. I still think that it’s valuable to a project to capture what they’ve done leading up to the review. But I wonder if the energy that goes into this document could be better directed at something with a little more shelf-life. Like, perhaps, a “new and noteworthy” document for the release.

So here’s what I’m thinking. Keep in mind that we’re still very early in this process and that this is little more than an idea at this point.

At the beginning of a development cycle, projects are required to provide a project plan in the standard format. The project plan document has a handy spot for listing release dates. Through the plan, the release dates are easily accessible by interested parties (users, contributors, adopters, and the broader community). We can even parse out these dates and include them on the “What’s New” page and RSS feed.

So each project can use their plan (in the standard format as required by Board mandate) as the mechanism to notify the community of the release. This gives the community the project’s entire development cycle to get involved, ask questions, challenge assumptions, and what-not.

When a project is ready to complete their release (as documented in their project plan), they get IP Log approval, put the finishing touches on their “new and noteworthy” documentation, and open a bug that states that they’re ready to release. Either the project’s PMC or the EMO (or both) adds their +1 to the bug and Bob’s-your-uncle. The approval is required to ensure that the aforementioned principles (and documentation requirements) have been observed. By this point, however, approval should be little more than a rubber stamp since the PMC and EMO will have been aware of the pending release for some time.

Frankly, if the community hasn’t gotten involved by this point, I’m not sure how adding an additional week of review time will improve matters…

I like this approach because the two documents that are needed (the project plan and “new and noteworthy”) (a) are things a project should be doing anyway, (b) are, at least in the case of the project plan, actual requirements set down by the Eclipse Board, (c) convey the really important information that is contained in the review documentation, and (d) are immediately useful. Correct me if I’m wrong.

Again, this is just an idea right now. It’s something I’d like to explore. In my mind, this should be easier for projects and more valuable for the community. I believe that it is a natural evolution of the process.


This entry was posted in Community, EDP. Bookmark the permalink.

5 Responses to Revising Eclipse Development Process: Release Reviews

  1. Pascal Rapicault says:


  2. Chris Aniszczyk says:

    I’m conflicted here Wayne. I actually read most of the release reviews for information about the project that is hard to obtain being an outsider on a project. This may be a good change as long as projects are REQUIRED to produce the new and noteworthy documentation along with a release. However, the quality of N&N tends to vary amongst projects. The release review has a way to force projects to reflect over what they have done in the past. I think that is valuable in itself.

  3. Chris Aniszczyk says:

    You may also want to summarize this post in an email to the list

  4. Dave Carver says:

    I think the key here is keeping the Release Review documentation to just what is needed. Having been through and helped create much of the XSL Tools release review documentation in the past, I can say I think a lot is over kill. I also tend to agree with Chris, New and noteworthy is fine for a summary and highlight, but there needs to be a middle ground. Ideally the documentation would be updated as Milestones occur, so that by the time it comes to a release, a project could technically have all the documentation ready to go at one time.

    I do agree though that much of the release review documentation for many projects just is not read. Most people if they do read it, are skimming not reading the whole thing.

  5. sree says:

    great blog post


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s