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:
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
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.