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

Why the gr_lenny ballot is the way it is


        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.fsf@mid.deneb.enyo.de>
Message-ID: <871vxczbww.fsf@anzu.internal.golden-gryphon.com>

        No one seemed to want such combinations enough to follow up on

        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

        The permanent solution proposals, if they fail to pass, may be
 discussed, modified, and brought to the table again. 

"Those who will be able to conquer software will be able to conquer the
world."-- Tadahiro Sekimoto, president, NEC Corp.
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: