On Sun, Nov 23, 2008 at 07:43:05PM +0000, Manoj Srivastava wrote: > 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 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_. > > 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 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. > > 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. 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. > > 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 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. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpT9qzoNLsnf.pgp
Description: PGP signature