Re: call for seconds: on firmware
On Sun, Nov 23 2008, Pierre Habouzit wrote:
>> On Sun, Nov 23, 2008 at 06:29:26PM +0000, gregor herrmann wrote:
>>> On Sat, 15 Nov 2008 09:45:56 -0600, Debian Project Secretary wrote:
>>> Since some people have had trouble reading the proposals, I am
>>> including a short impact of the proposal list below the proposal.
>> Thanks for listing the consequences of the different choices.
>> 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
>> As a side note:
>> I guess what makes this vote confusing (at least for me) is that we
>> try to answer several questions (roughly equivalent to the
>> consuequences) in one vote ...
I think the primary question that started this line of proposals
was how to resolve the presence of allegedly sourceless firmware in the
kernel image. Some of the solutions to that issue have longer term
impact, and could be considered on their own merit. However, since they
also solve the Lenny issue, I think they belong on this ballot; since
we can resolve about one way to solve Lenny, and then we get a second
chance to come to a different (and conflicting) resolution about Lenny
by the second or third votes.
> I have a problem with that. Only (4) is _really_ actively taking sides
> on that. All the other votes are completely unrelated to the Release
> Team decision.
I think we need to resolve what to do with lenny first: and if
it is to let the release team have to power to decide whether possible
DFSG/GPL violations can be present in the Debian system is one way of
resolving this.
> I feel there are two votes, the one about Should we release with or
> without the firmware issues, which de facto endorse or rescind the
> Release Team decision, and the rest.
What is the rest? At this point, I see no options on
the ballot which will _not_ resolve the Lenny release issue.
> Mixing the two issues suck badly, because I believe that the project at
> large would want to allow the release team to ignore the firmware bugs
> for the release (hence endorsing our choice), while there is no
> consensus on the firmware source issues. At least I _believe_ it's where
> the project stands, and it did, twice, in the past.
The project can say so again. Option 5 is defined for that;
which essentially says that the project allows people to say release
Lenny as long as there are no proven DFSG violations.
> So tying the "allow firmware without / with source" or whatever change
> related to that, _with_ the question about "what we do for lenny" are
> definitely a bad mix that sounds rather unfair and blocking people from
> at the same time not wanting to slow the release for this issue, but
> still confirming sourceless firmwares in main are against their
> interpretation of the DFSG.
I take it you do not think option 2 meets this goal, which says
that for Lenny we shall ignore possible DFSG violations in the kernel?
Or Option 5, which says we'll not hold up the release for things we
just suspect are DFSG violations? Even option 3 allows us to just
ignore the DFSG violations for the release.
Would you just want to add something that just says "We like to
say that we do not like sourceless firmwares in main, except when it
come to releases, and then that is fine" to the proposals 2 and 3?
I am unable to see the distinction between what you seek and
options 2/3.
manoj
--
The shortest distance between two points is under construction. Noelie
Alito
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: