On 13 Jun 2016, at
03:50, Wayne Beaton <
wayne@xxxxxxxxxxx> wrote:
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.
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
I agree. The suggestion was born out of desperation.
The problem has been mitigated in the short term.
I intend to bring this up with the Planning Council to sort out
means of identifying problems earlier.
I fought for explicit opt-in to ensure that project teams are
paying attention year-after-year, but it seems that more is
needed.
e.g. require that projects submit an IP Log for review on M6. Or
maybe just certain projects.
Wayne
On 11/06/16 04:17 AM, Gunnar
Wagenknecht wrote:
Frankly,
I think it's not helpful if we step in and
help pushing the project past the finish line. Can the other projects
be made aware of the situation? I'd like to get a sense of how critical
XWT is. Maybe there are volunteers for helping XWT if it's critical
enough for them?
-Gunnar
Greetings PMC.
We have a situtation.
The XWT project team has apparently stopped participating in the
simultaneous release process. According to the EDP, the XWT
project must engage in a release review before the version 1.2
bits can be released. If they do not engage in this review, then
we have to remove them from the simultaneous release.
Unfortunately, at least two other projects in the simultaneous
release depend on XWT, so removing it will be at least a little
bit painful. I'm assuming that these dependent projects have done
sufficient testing of their features that depend on XWT.
Theoretically, if we remove them from the release, the projects
that use XWT can revert to an earlier version. That's one option
to consider. Perhaps those projects may be able to extract
themselves from XWT.
Another option is for us to declare the project dysfunctional,
retire the current project lead and team, and then push it through
the process ourselves. Then, following the release, we first look
for another team to take over the project or take steps to
terminate and archive the project.
I've sent a note to the dev-list and personal note to the project
lead in a last-ditch effort to get a response. If we don't hear
back before Monday, we'll have to make a decision.
Wayne
