Why the gr_lenny ballot is the way it is
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.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
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 <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: