[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

The shortest distance between two points is under construction. Noelie
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: