I'm thinking of the IP Log on M6 as a checkpoint.
I made several announcements during the release cycle that were
obviously ignored.
I'd like to add an action to the process and getting some
problematic projects to submit an IP Log feels like the right
action as that actions fixes multiple problems.
First, we know if the project team is not paying attention.
Second, I actually regularly uncover problems when I review IP
Logs. The IP Team is scrambling today because a handful of project
teams needed some last minute CQs to cover off some third-party
libraries that they've been using for a couple of months without
properly registering. Most of them are piggyback requirements
(which will hopefully go away anyway), but some are new versions
of already approved libraries, and some are entirely new
libraries.
Discovering these problems early is important.
But I'd like to do this without punishing all projects, so I'll
need to come up with some criteria for requiring this extra step.
Frankly, my main concern is to ensure that project teams that are
participating in the simultaneous release are actually paying
attention. Having a mid-cycle event is more about identifying and
mitigating problems, not punishing.
Wayne
On 13/06/16 03:11 AM, Gunnar
Wagenknecht wrote:
On 13 Jun 2016, at 03:50, Wayne Beaton <wayne@xxxxxxxxxxx>
wrote:
I fought for explicit opt-in to
ensure that project teams are paying attention
year-after-year, but it seems that more is needed.
A project must define a release record matching the release
train date. Isn't that sort of opt-in? Defining the release
record is an explicit action done by the project leads. I think
that should be enough.
e.g. require that projects submit an IP Log
for review on M6. Or maybe just certain projects.
Requiring an IP Log earlier does not help with agility.
Especially if we want to release more often.
This sounds like a lot of work - especially given that there
is no one available for implementing an automation around this -
but here is what I'd like to see:
Instead if the implicit date matching of the release record,
project MUST confirm participation in a release train as well as
participation in the common repository (these are two different
things). Note, it can be as simple as two checkboxes on the
release record form when entering the release date. But it would
solve the ambiguity with projects releasing on an earlier date
but still submitting to the release train.
Next, release train status flags are introduced for release
records. After every milestone, there is some logic verifying
the new bits have been submitted by a project (if the release is
pending) or not. If no new bits have been submitted, the project
will be nagged to re-confirm their participation in the release
train. If they do not re-confirm within XX days, they are
declared "off track" and are effectively out, i.e. the release
train participation flags are removed and the release record is
set "on hold" (maybe that's too drastic).
The same "nagging" and re-confiming should happen when
required documentation must be submitted.
A report could be send to cross-project regularly and be made
visible on the website.
There also needs to be a lot more validation for those
requirements of the common repo. For example, it should be
possible to detect projects relying on bits that are "off track"
and nag those projects as well.
-Gunnar
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/technology-pmc
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
