Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Simultaneous Release Opt-in announcements

CDT is participating, of course. We don’t know what release yet. At this point it’s very likely a maintenance release off the 9.5 branch. But as we are pushing those out on demand, we won’t know which one until the rampdown starts when we’ll lock it in.


But, yes, at the very least can we create another mailing list for these. It’s created a lot of noise in my inbox and we have other very important topics to look out for.




From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Monday, July 16, 2018 10:38 AM
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Subject: [cross-project-issues-dev] Simultaneous Release Opt-in announcements


These "kind of annoying" announcement messages serve a couple of purposes. 


They ensure that project teams are actually engaged on the primary communication channel for the simultaneous release. This comes in handy, for example, when project teams change composition (e.g. key players move on), knowledge gets lost, or project teams otherwise end up disengaged. When we notice that projects are missing at the opt-in deadline, it's way easier to mitigate than when we notice it at the end of the release cycle. FWIW, we have to chase down at least a couple of projects every year.


The requirement to make an explicit communication basically forces project teams to create a release record and start their planning and communication regarding the release. Of course, this presupposes that creating a release record at the beginning of a release cycle is valuable. 


The Eclipse Development Process states, in part:


Projects are required to make a project plan available to their community at the beginning of the development cycle for each major and minor release. The plan may be as simple as a short description and a list of issues, or more detailed and complex.


The Architecture Council is in the process of updating the Eclipse Development Process. If anybody would like to consider changing any of these, I recommend that you take that up with your PMC representative on the council.


With the evolution of the simultaneous release to a rolling release process, I half expected that the Planning Council might decide to require explicit opt-in on a quarterly basis. I'm delighted that they've instead decided to not raise the burden and instead just require a single annual check in.


I am thinking, though, that with the increase in frequency of releases, it's time to rethink how we track participation in the release. We may consider investing some energy in deriving this information from the aggrcon files. This, of course, assumes that tracking this information is actually valuable (and ignores that we have some projects that participate in the simultaneous release, but do not contribute bits to the aggregate repository). The explicit tracking has proven helpful for marketing purposes, and helps those of us who work at a higher level than an individual project.


I don't know how to achieve all of this in an easier manner than a once-per-year email. If you have suggestions for alternatives, please connect with your PMC's Planning Council representative to have them bring this discussion to the PC.





Wayne Beaton

Director of Open Source Projects

The Eclipse Foundation

Back to the top