The Eclipse Development Process has a notion of phases. Two of those phases are "Incubating" and "Mature".
While in both of these phases, an Eclipse project operates in basically the same manner: only committers can push content, committers are brought on board by election, committers accept contributions, etc. Projects in the incubation phase can issue major, minor, and service releases. Traditionally, a project in the incubation phase numbers their releases < 1.0 (e.g. "0.7"), but there is no requirement to do so.
Incubation is a phase, or state, for a project. A project in incubation is a flag for adopters and the community at large that the project team is still learning the various processes that Eclipse project teams follow, or that the content produced is either unstable or volatile (e.g. APIs are likely to change while a project is in incubation). Note my use of the word "or" in the previous sentence: a project with a stable code base that has just moved to the Eclipse Foundation (with committers who are new to our process) starts in incubation.
The IP process provides some additional flexibility for projects in incubation; the implication being that there may be some modest increase in intellectual property-related risk (especially when combined with a new development team who don't necessarily understand the IP Policy). We decided to, for example, maintain an inconsistent IP state for an extended period of time and did overlook a small number of issues while bringing EE4J up to speed (we're going to have to address these issues).
All of the new projects in Eclipse EE4J are in the incubation phase (EclipseLink left incubation years ago).
To leave incubation, a project team must engage in a graduation review (graduation reviews are typically combined with a progress or release review). During that review, the project team must demonstrate that:
- The project team understands and implements the EDP and (for specification projects) the EFSP, and understands their obligations under the Eclipse IP Policy;
- The APIs are stable; and
- The content produced is of "Eclipse Quality"
In practice, this takes the form of a few extra sentences in the documentation associated with the review (after, of course, actually learning the ropes and stabilizing the content quality).
The EFSP does not mention incubation, which means that it inherits the concept from the EDP.
In my mind, it is perfectly reasonable for a specification project to create a final specification while in incubation. The IP Flows are triggered by "Checkpoint Reviews" as defined by the IP Policy (Creation, Progress, Release, and Graduation reviews are collectively referred to as Checkpoint Reviews by the IP Policy). Projects in incubation engage in progress and release reviews just like projects in the mature phase, so all IP Flows work the same way.
A theoretical Final Specification produced by a project in the incubation phase needs to be marked as "incubating" as a flag to adopters. Note that I didn't enforce this during our migration to avoid adding "one more thing" to the list.
All of this discussion may be academic. As we restructure our existing projects into specification projects, I recommend that we engage in coincidental graduation reviews so that all our first round of Final Specifications are produced by mature phase projects. The work done to date provides a good demonstration that the project teams understand what is required of them, and the content is clearly stable.
HTH,
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
