Re: [cross-project-issues-dev] Simultaneous Release Opt-in announcements

["Daniel Megert" <daniel_megert@xxxxxxxxxx>]

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

Exactly, see https://bugs.eclipse.org/520775.


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

Well, this is
only works for one out of four releases, since, as you said yourself, the
communication is only required once per year, but we 4 releases per year.

Dani



From:
       Ed
Willink <ed@xxxxxxxxxxxxx>
To:
       cross-project-issues-dev@xxxxxxxxxxx
Date:
       16.07.2018
16:51
Subject:
       Re:
[cross-project-issues-dev] Simultaneous Release Opt-in announcements
Sent
by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

---

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
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Virus-free. www.avast.com

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev