I'd like to add this to the agenda for our next call.
Here are some suggested dates for the simultaneous release. I've added in the dates for the milestones and release candidates to provide some context.
The dates that I'm suggesting are highlighted in bold.
October 5/2018 - Opt-in deadline
ASAP - Create your release record (for new releases)
ASAP - CQ Submission deadline (specify that the CQ is required for Oxygen)
October 19/2018 - Milestone 1
November 9/2018 - Milestone 2
November 28/2018 - IP Log submission deadline
November 30/2018 - Milestone 3
December 5/2018 - Review materials due
December 5/2018 - New and Noteworthy entries due
December 7/2018 - Release Candidate 1
December 14/2018 - Release Candidate 2
December 19/2018 - Release reviews
December 19/2018 - Eclipse SimRel 2018-12 GA
Regarding opt-in... I'd like to avoid the explicit opt-in, especially for projects that are not contributing any new bits. I do, however, want to make sure that we identify projects that aren't paying attention early enough to do something about it.
What do we actually need to capture for opt-in? Can we just gather this information from the aggregation metadata (e.g. if the aggregation file is enabled, the project is in)? How can we consistently tell if a project has contributed a new version? (directory diff?)
What is the join-in/drop-off deadline? I'm thinking that the new bits have to be added or removed in either M1 or M2...
I've added a "New and Noteworthy" date. If we're going to have any potential to make any of use of this in marketing, earlier is better than later. I no longer have the bandwidth required to build an aggregated New and Noteworthy document. If somebody wants to step up, that would be great. Otherwise, I believe that our best bet (I believe that has already been discussed) is to ask the webdev team to set up a page with pointers to individual project pages. To that end, I figure that we should just open a bug to act as a collection point.
In my mind some consistency in the format of New and Noteworthy would be valuable, but I have no energy to encourage/enforce this.
I've moved the IP Log three weeks ahead of the release. I'll use this opportunity to re-iterate that project teams can continue to receive contributions and make changes that impact the IP Log following this date. The IP Log check's purpose is to verify that IP is being properly tracked, not to reflect the IP state of any particular release.
The earlier that CQs for entirely new-to-us third party content are created, the better. We can be a lot more flexible with piggybacks and--to some degree anyway--new versions of approved content.
Note that the Eclipse Architecture Council is working on some changes to the EDP that will change how we do releases. These changes are anticipated to take effect at the end of the year; until they take effect, the existing process must be followed.
Projects that are putting new bits into the December drop must engage in the release process as described. This means that major and minor releases require a Release Review. Per the process, service releases (bug-fixes only) do not require a Release Review or an IP Log review.
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Meet us at EclipseCon Europe 2018: LUDWIGSBURG, OCTOBER 23 - 25