The Eclipse Development Process (EDP) requires that a project team engage in a successful progress or release review before creating a formal release. We use progress and release reviews as an opportunity to validate that a project team is following the open source rules of engagement, and are consistently implementing the EDP and the Eclipse Intellectual Property (IP) Policy.
Progress and release reviews are fundamentally the same, differing only in timing and intent. A progress review can occur at any time in the development cycle, and there is no immediate expectation that the project team will make a release. In contrast, a release review generally occurs at the end of a release cycle and it is generally expected that a release occurs shortly after the successful completion of the review (though the EDP makes no timing requirements other than that a release review complete successfully before the release).
Following a successful progress or release review, a project team may engage in any number of releases for an entire year (though, the project leadership may compel a project team to engage in extra reviews should they be deemed necessary). While a formal review is not required for every release, project teams must ensure that all related due diligence is completed before IP is included in a release. Project teams are required to implement the IP Policy at all times.
The basic framework is the same, but the requirements are a little different for open source projects engaged in specification development (what the Eclipse Foundation Specification Process (EFSP) refers to as “Specification Projects”). These projects must engage in at least one successful progress review midway through their development cycle, and a successful release review prior to every official release. For specification projects, reviews come with extra requirements to validate that that specification process is being consistently implemented, and that the work being done by the project is in scope.
To start a review, a project team assembles review materials and delivers them to their Project Management Committee (PMC) for approval. In parallel, the project team also submits their log of intellectual property contributions to the Eclipse IP Team for their approval. One those approvals have been obtained, the Eclipse Management Organization (EMO) schedules the review and invites the community at large to weigh in.
The EDP requires that review materials be made available to the community for feedback for a minimum of one week. Theoretically, it is during this time that a community member might voice concerns. An Eclipse Foundation member company might, for example, object to a release that they believe infringes on their intellectual property. I say “theoretically”, because this rarely happens… reviews tend to conclude successfully.
Reviews tend to conclude successfully in large part because all of the work is done in accordance with the open source rules of engagement. Frankly, one week is far too short a period of time for a community member, adopter, or other interested party to engage in any sort of comprehensive review. It is helpful to think of progress and release reviews as the end of a review cycle that begins at the start of the development cycle. Since all open source work must be done in an open and transparent manner, anybody may observe the activity of the project team, and join in the conversation at any time. An interested individual or organization can literally engage with the project as long in advance of a review and/or release as they’d like.
In short, if you’re just starting to dig into an open source project during a review, you’ve waited too long.
The release process is described in detail in the Eclipse Project Handbook.
