At the beginning of October 2013, I delivered a draft of the next revision of the Eclipse Development Process to the Eclipse Architecture Council for their review and approval. The “delivery” was actually pretty uneventful as the council has been actively involved in the construction of this draft for several months. I intend to present this to the Eclipse board of directors during their December meeting; with their approval, the new revision will go into effect early in 2014.
What does this have to do with the EDP? Nothing. I just like trains.
This revision is a relatively minor one that doesn’t contain too many surprises. The primary focuses are:
- Simplification and streamlining; and
- Social coding.
The new revision is here. There’s link on the right that you can use to view the document with the changes since the previous revision highlighted. The diff engine that I used had some trouble with the HTML, but I think that I’ve managed to coerce it to do an adequate job.
You’ll notice that section 8.2 “History” isn’t complete; I’ll piece that together shortly.
The changes have all been tracked in Bugzilla, under the Community/Architecture Council component. Here are some of the highlights (note that the titles of these bugs may change, and that additional bugs may be added).
Bug 367236 Updates to the EDP for 2014
This is the master bug for all changes considered with this revision. All other changes are “blockers” on this bug.
Bug 345755 Eliminate the pre-1.0 versioning requirement for incubating projects
The current revision of the EDP makes an explicit requirement that incubating projects can only use pre-1.0 version names for releases. The logic is/was that naming a release 1.0 implies that the project is mature. Combined with our incubation branding requirements, this requirement is redundant. Further, we have had to grant exceptions to this rule several times in the past to accommodate projects that have already produced and distributed post-1.0 releases. The WindowBuilder project, for example, was granted this exception; it would have been confusing and disruptive to the project’s existing user and adopter base to force the project to produce, say, a 0.7 release while in incubation.
Bug 415715 Fix capitalization
The pseudo-legal capitalization style in the document has bothered me for years. I’ve always found it distracting. With this revision, I’ve tried to revert the content to use standard capitalization rules. I used this opportunity to make some other minor cosmetic changes, like changing “Sub-project” to “subproject”.
Bug 418468 Confusing terms – incubator project vs project in incubation phase
The new revision further distinguishes between the incubation phase and an incubator project by consistently using the term “permanent incubator”. Permanent incubators never graduate, and don’t do releases. They are subprojects for mature-phase projects to use to incubate new ideas and grow new committers.
Bug 325004 Eliminate Continuation, Promotion, and Move Reviews
We actually eliminated move reviews in a previous revision. Moves were turned into a potential aspect of a restructuring review. Further, with this revision we acknowledge that we don’t use promotion reviews to create top-level projects. The last project promotion we did was for Mylyn; in that case, we used a restructuring review in combination with board of directors’ approval of the new top-level project charter. There’s no need for a special type of review.
Finally, we eliminated continuation reviews. We haven’t done a continuation review for years. In discussion, the Architecture Council decided that it’s the project’s PMC’s responsibility to make sure that the project is progressing and it’s really up to the PMC to determine what sorts of actions need to take place and how.
Bug 331397 EDP should say more about project namespaces
We added a line to indicate that projects are expected to work within assigned namespaces. Additional namespaces can be assigned by the EMO at the request of the project. The intent is to avoid namespace collisions by restricting projects from spreading out too far. Namespaces are programming language- and technology-specific; in practical terms, projects that are implemented using Java, for example, are required to use a namespace along the lines of org.eclipse.<short-name>.*.
Bug 344041 Yearly reviews required
We removed the requirement to do yearly reviews. Again, the Architecture Council decided that it’s the PMC’s responsibility to ensure that a project is progressing at the right pace (and to determine what “right pace” means).
Bug 368196 Graduation is just a special kind of release
The title of this bug needs to be fixed. The discussion started with a suggestion that we merge graduation and release reviews together. In the end, this manifests as a single sentence that says that graduation reviews are generally combined with release reviews (a reflection of reality).
Bug 415626 Restructuring review section too verbose
This is a response to my getting carried away in a previous revision. The description of a restructuring review was far too verbose, so we trimmed it down to be more in line with the level of detail afforded to the other types of review.
Bug 415629 Perpetual “Incubator Projects” should not require a creation review
Perpetual Permanent incubators can only be created by projects that are in the mature phase (i.e. only projects that have graduated). Given the nature of incubators, a community review in advance of their creation has little value. A mature phase project can just ask for a permanent incubator.
Bug 415696 Move paragraph concerning releases from section 4.2 to section 6.4
With this move, we rename section 4.2 to “code and resources” to better reflect the actual content which is concerned with describing the relationship between a project, it’s code, and various resources with their committers. Section 6.4 is concerned with releases, so moving the paragraph on that topic to that section just made sense.
Bug 415714 Remove reference to “Bugzilla”
This one removes a single sentence that had previously indicated that projects have a Bugzilla presence. We removed it because references to specific technologies are not appropriate in a process document.
FWIW, the EDP does reference UNIX groups, but does so to convey a point, not enforce specific technology.
Bug 416636 “Top-Level” is not a phase
The project lifecycle previously suggested that progression to top-level project is a natural growth path for projects. It is for some, but most projects will never be top-level projects.
Bug 418346 Reduce redundancy in 2.3 “Three Communities”
Three bullets in this section basically restate the points made in the first paragraph. We decided that they didn’t add value and so removed them.
Bug 367235 Confusing language regarding termination of project lead role
A minor rewording to improve the readability of the process for terminating a project lead under exceptional circumstances.
Bug 417883 Termination reviews not required for proposals
Frankly, I can’t believe that I missed this one over so many past revisions. The lifecycle diagram had a path from the proposal stage to archive stage that required a termination review. If I can’t get a proposal to the creation review stage, then running a termination review seems a little silly. Proposals can be shipped off to /dev/null after an extended period of dormancy, or at the request of the proposers.
