Progress and Release Reviews
The Eclipse Foundation Development Process (EDP) describes a release as anything that is distributed for adoption outside of the committers of a project (effectively, if you stamp something with a version number and tell the general audience to download it, it’s a release). Appropriately labeled nightly, integration, and milestone builds are not considered releases.
Further, the EDP describes a requirement for all Eclipse projects to engage in a review prior to creating a release. Traditionally, this has meant that an Eclipse project team must engage in a release review. A few years ago, we added the notion of an equivalent progress review; the primary difference between a release review and a progress review is that a release review is aligned with a specific release and a progress review is not.
Following a successful release or progress review, an Eclipse project team may make as many releases (major, minor, or service) as necessary for a full year before having to engage again. Note that whether the project team engages in a review or not, the project team is responsible for ensuring that all intellectual property contained in all releases has been vetted per the Eclipse Intellectual Property (IP) Due Diligence Process. Note also that specification projects are required to engage in a release review for every release.
If your project is due or overdue for a review, please engage with EMO at your earliest convenience.
The EMO is exploring an option by which we will initiate progress reviews on a project’s behalf. Our thinking at the moment is that reviews start with the EMO doing a health check on the project to ensure that the project team is doing all the right things to be a good open source citizen and is correctly implementing the EDP and Eclipse IP Due Diligence Process, before engaging the project team and PMC to remediate any outstanding issues that we identify. The successful completion of an EMO-initiated progress review will put the project in a state where it can release for a full year without requiring an additional review.
Our hope is that we may be able to effectively eliminate release reviews and reduce the burden of implementing the EDP for both project teams and the EMO. It’s still early in the process, but we’re hopeful that we’ll be able to make this work for most of our projects. Again, we’re just starting this experiment: we’re not actively soliciting volunteers or rolling this out at this point.
Due to the extra intellectual property burdens inherent in specification work, release reviews will continue to be required for specification releases.
If you have comments or questions, please pose them on the GitLab issue that we’re using to track this work.