Re: First call for votes for the Lenny release GR
Brian May dijo [Thu, Dec 18, 2008 at 11:45:47AM +1100]:
> > (...)
> >A) If we trust or not the release team on making the right choices of
> >which bugs to ignore and which not (regardless of this being firmware
> >issues or what have you). This is from now on, not just for Lenny.
> >B) If we want to allow sourceless firmware in Debian, defining
> >firmware in a way that doesn't give a waiver to anything else without
> >source. This is also from now on, not just for Lenny. But it's only
> >for firmware, not for everything with licensing problems.
> >C) If we want to allow stuff with some problems into Lenny, as we
> >already did for Sarge and Etch.
> I think the concern is, what if the results conflict?
> e.g. if we get a "No" for (C) but Yes for (A). We trust the release
> team to make the right choices but we don't trust them to make the
> right choices for Lenny?
> My suggestion would be to vote for (C) first, and then decide the
> wording on (A) and (B) depending on the outcome of (C). In which
> case, even if there is a conflict, the wording can clarify if the
> second vote overrides or doesn't override the first result.
I agree with your view, as it would also free the release team to move
forward the release while we continue discussiong A and B. I would
_really_ love to get this settled for good (i.e. to solve A and B as
Still... Everything lends itself to interpretation. In the case you
mention, if a GR says "No" for C, then Lenny will be delayed until
said problems are solved. And if then we vote "Yes" for A, they will
know the firmware issue is off-limits (via a GR, of course) - They
will have the power to mark lenny-ignore a FTBFS if you may, but not a
non-free firmware inclusion. Which is still an outcome.
Gunnar Wolf - email@example.com - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF