Hi, This whole set of discussions and proposals started a couple of months ago, when concerns were raised about firmware blobs, dfsg violations, and the release. This, after a round of disuccion, led to three proposals on how the release should be conducted, in view of firmware blobs currently in the linux kernel packages.
The proposals led tyo a great deal of heated responses, and whole slew of related proposals were produced -- related, as in all of them dealt with firmware blobs and difsg violations, and dealt with the release process, and some of them were for handling just the current release, others sought to solve the issue of firmwarfe for this and all future release4s, either directly, or delegating the decisions to a group of developers, and away from the general resolution mechanism of resolving this for future releases. All of these related proposals would handle, one way or the other, the issue of this release and firmware. Some of them would grant dispensation to more than just firmware, and some of them solve this problem for future reelases as well, but all would resolve the release _now_. Also, some of the proposals are indeed orthogonal, or, at least, mutually incompatible; and in some cases, selecting one option makes the others moot. Yes, some of the options on this ballot have long term impact, but they are also equally capable of solving our "What to do about Lenny" problems. Since they all solve the Lenny issue, they are relevant, and related, solutions for the issue. I do not think throwing options out because they are not of a narrow and limited scope is right. The proposer and sponsors can withdraw them, if they think the scope is too broad for the problem at hand. No one else should be removing them from consideration as a solution to the Lenny issue. Now, we have been fairly non-anal about differing options on out ballots being formally proposed as amendments (I amend proposal foo, and replace all the words in that proposal by these below ....), I did not see any reason to change being anal retentive for just this vote. The ballot is a mess. While I think the related proposals should be placed on the same ballot overrides ere, the prooposals are not truly all orthogoanl. We could, for example, do the allow the delegation of DFSG violatio decisions to the release team, _and_ also rulke that firmware should be granted special dispensation in the DFSG. So, while the power set of the options is not feasible, we could have a slew of options combining the various proposed options, if people wanted to vote on a compatible set of options. This was discussed a month ago, in early november, giving people who wanted to vote on a combination of optiosn plenty of time to propose favourite combinations. Message-ID: <87ej1cd11m....@mid.deneb.enyo.de> Message-ID: <871vxczbww....@anzu.internal.golden-gryphon.com> No one seemed to want such combinations enough to follow up on that. Also, splitting a vote into multiple ballots, with related proposals affecting the same action (lenny release, for instance) , is a horrendously bad idea -- since the massive amounts of strategic voting possibilities will taint the final result. Given that these proposals are strongly related, they should be on the ballot together. The permanent solution proposals, if they fail to pass, may be discussed, modified, and brought to the table again. manoj -- "Those who will be able to conquer software will be able to conquer the world."-- Tadahiro Sekimoto, president, NEC Corp. Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org