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.
