| Re: [technology-pmc] Pushing XWT past the finish line |
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.
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 |