Hi Wayne
I don't think tracking the aggrcon will work since some projects specify
a 'my-build' repo and never need to touch the aggrcon; of course we all
get to enjoy the consequences of their broken builds. If everyone had to
specify a build specific repo, then aggrcon could work for this purpose.
You seem to have ignored the at least 3-way suggestion of using the PMI
Release Record. Obviously this requires that a Release Record is created
in order to have somewhere for the checkbox.
Regards
Ed Willink
On 16/07/2018 15:38, Wayne Beaton wrote:
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.
Thanks,
Wayne
--
Wayne Beaton
Director of Open Source Projects
The Eclipse Foundation
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
