Every couple of years, I work with the Eclipse Architecture Council to revise the Eclipse Development Process (EDP). The EDP is the document that describes the structure of projects, relationships between projects and committers, and the sorts of activities that projects are expected to engage in.
After many years and many revisions, it’s past time for a complete (or near complete) rewrite. That’s an exhausting thought, frankly, but it’s my hope that we’ll be able to do just that.
I’ve started gathering ideas for how the EDP can change on Bug 463857; this is an umbrella bug to collect the issues that need to be addressed. I’ve already added a few blocker bugs for some issues that I feel need to be addressed. Feel free to add your comments and other blockers as you see fit. Please do join in the discussion.
The first thing on my list is release reviews. Originally, a release review was an event: a conference call on which the project was required to defend their release to the community (or at least that subset of the community that joined the call). In those days, review materials needed to be prepared and disseminated a week in advance of the call to allow the community to prepare. But as community participation dropped, so to was the conference call and we turned the week of review material availability into the review itself.
I’m not at all convinced that there’s much value in the formal week of waiting to release. The community rarely–if ever–comments on release review documentation and since we set reviews up to succeed, they never fail. Further, I’m of the mind that anybody who is interested in an open source project is either already following the progress of the project or should be. If you’re waiting for the release review to be notified that something new is coming from your favourite open source project, it may be time to consider getting more directly involved with project discussion.
For releases, I’m thinking:
- Get IP Team approval of the IP Log;
- Get Project Management Committee (PMC) Approval of the release; and
- Ship it.
Documentation requirements are the PMC’s call. Personally, I think that it’s totally reasonable to require that projects produce at least a single paragraph that describes the nature of the release in broad terms. And planning needs to happen in some form: either as a formal plan or more informally via target milestones on Bugzilla records.
Add your thoughts on Bug 415620.
