Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-committers] 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).

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.  We're tracking the work here.

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 rather than on this thread.

While I have your attention...

The Eclipse Foundation community awards are back for 2021! The Eclipse Foundation has a vibrant community of many dedicated individuals, who deserve to be recognized for their contributions. To recognize our community members, we will be presenting awards for Top Committer, Top Newcomer Evangelist, Top Contributor, and Lifetime Achievement at EclipseCon 2021.

As these are community awards, we are asking the community to get involved by nominating someone they think is deserving of an award, and voting to select the winners. Nominations for all four of the awards will be collected via bugs on GitLab from May 3 to May 28, 2021. We will then hold voting for the Top Committer, Top Newcomer Evangelist, and Top Contributor awards. The Lifetime Achievement award winner will be selected by the Eclipse Foundation team.

Details on the awards, nominations, and voting can be found on the Eclipse Community Awards page.

The call for participation for EclipseCon 2021 is open. Don't miss your opportunity; propose a talk now.

Wayne
--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation


Back to the top