gregor herrmann <[EMAIL PROTECTED]> writes: > In order to make it easier for me and maybe others I'm trying to compact > them into a single table below (the FD column is from Russ' followup > mail to -vote). > > v Consequence / Proposal > | 1 | 2 | 3 | 4 | 5 | 6 | FD > -----------------------------------------------|---|---|---|---|---|---|--- > i require source for firmware in main | Y | N | N | N | Y | N | Y > ii allow Rel.Team to ignore SC violation bugs | N | N | N | Y | N | N | N > iii What do we do for Lenny | W | R | R | R | R | R | W > iv modify foundation documents | N | N | N | Y | N | Y | N > v override foundation documents | N | Y | Y | N | N | N | N > -----------------------------------------------|---|---|---|---|---|---|--- > Y(es) N(o) R(elease) W(ait)
I'm pretty sure from the further analysis, and I think Manoj confirmed, that FD is N-N-R-N-N. Even if some people think that set of choices is nonsensical, my understanding of the current situation is that the release team has ruled, as DPL delegates, that the current situation does not violate the SC sufficiently to warrant removing the relevant packages from main or delaying the release (this is not the same thing as ignoring SC violation bugs under the project governance process). In the absence of an override of that delegate decision, it stands. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
