Re: call for seconds: on firmware
On Sun, Nov 23 2008, Pierre Habouzit wrote:
>> On Sun, Nov 23, 2008 at 07:43:05PM +0000, Manoj Srivastava wrote:
>>> On Sun, Nov 23 2008, Pierre Habouzit wrote:
>>
>> 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
>
> No it's not, the original question was "do the release team has powers
> to decide that it's okay to ignore DFSG violations for a release". The
> firmware discussion came _then_.
The answer is simple: the constitution gives them no powers to
override the foundation documents on their own. Since all powers to the
delegates flow from the constitution, that is that, no?
>> > 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.
>
> No, we need what to do with the process of releasing first. To me, the
> questions of endorsing the RT or not, and delaying the release or not
> are one and the same, and are completely distinct from the sourceless
> firmwares issues in Debian, even if loosely correlated. And again, the
> releasing issues _HAVE COME FIRST_, and are the very source of all the
> rest. It's just that I feel that _you_ don't care about that, just about
> the firmware issues. I'm annoyed you don't see other people see two
> different problems here.
I think there is little non-technical blocking the release apart
from the firmware issue. There is no reason to delay the release (apart
from the RC bugs) than firmware in Debian (which is not being counted
as RC, since it has been downgraded)
>> > 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.
>
> For *****'s sake Manoj, have you read what I wrote ? There is no sane
> way to decide that the release team was right to lenny-ignore those
> bugs but _still_ reaffirm that the sourceless firmwares are still not
> OK as a general rule. This is a valid opinion, and I believe it
> concerns a fair amount of people in Debian, at least it's what past
> votes show unambiguously. I feel those people are betrayed. And FWIW
> I'm not one of them, I'm objectively opposing your choice here, not
> preaching for my church.
I guess I am obtuse, since I am still not seeing it.
a) No delegate can just ignore the foundation documents
constitutionallyy.
b) If the release team is correct, then there is no DFSG
violation, and the sourceless firmware in testing are rightly
there.
c) If the sourceless firmware is not OK, then how can the
release team have been right?
> huh, no that option rescind the RT decision. We didn't decide having
> sourceless firmwares was not a DFSG violation, we decided it was not
> critical enough to delay the release for that since the project stated
> that twice already.
No.
The first time, we decided to bring back the old social
contract for sarge, that did not say Debian was 100 % free. After
releasing Sarge, we made the change.
*THE RELEASE DID NOT VIOLATE THE SOCIAL CONTRACT AS IT STOOD*
The second time, we said the firmware must comply with the
DFSG. That meant, in practice, that the formware was considered to be
in compliance with the GPL, and thus the preferred form of
modification -- and no one could _prove_ otherwise.
*THE RELEASE DID NOT VIOLATE THE SOCIAL CONTRACT AS IT STOOD*
>> > 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.
>
> That's not the same, it doesn't decide if the release team was right or
> not, and is tied to _other_ decisions which prevent people from voting
> in conscience. They have to weight every option to vote for the one the
> _closest_ to what they think. To be frank, if I were in the position to
> support the release team in the fact that they _have_ de facto
> delegation to make the decisions they did, but still don't want to see
There is no de jure delegation, indeed, the constitution given
no delegate such powers.
> any sourceless firmwares seen as "OKish" wrt the DFSG, I would be
> _really_ annoyed to make a choice. This position is totally absent,
> because you have arbitrarily coupled different decisions together.
>
> This makes the vote a terrible mess where it's totally unclear what we
> really vote for and what the consequences here are. I dislike that
> beyond words.
You are free to add the missing option to the ballot. Just get
some seconds.
manoj
--
Only a fool fights in a burning house. Kank the Klingon, "Day of the
Dove", stardate unknown
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: