On Wed, Dec 17, 2008 at 4:15 PM, Manoj Srivastava <[email protected]> wrote:
> 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. No. As I've said, people want to vote separately for separate subjects, we don't want MORE options in this ballot. Please, no. Nobody claims the issues aren't "related", but not everything that is "related" deserves to be in the same ballot. There are three questions that need answering, and these questions are independent. You seem to be worried that having separate ballots would be "gaming" the system, and would be prone to "strategic voting". That might be true when the separate ballots actually hold competing candidates, however in this case, each ballot would answer a different question, so there's no such thing as voting for a less desired candidate in order for your desired candidate to win... Yes, all these questions are related to what will happen to Lenny, but that does not mean they should all go into a messy ballot. In this case, having separate ballots will more accurately reflect the position of the project for the 3 issues at hand: 1) What do we do with licensing bugs in Lenny? 2) Does the RT have the power to decide what bugs to ignore? 3) Do we allow sourceless firmware in Debian? These questions are related but separate, each person should be entitled to vote on how they feel about each of them. There's no "gaming" in this, just an accurate and simple way of finding out the position of the project on 3 related-but-separate subjects. Condorcet doesn't allow more than one "winner". And these option should all be allowed to win (you even said that if neither 4 nor 6 win, they should go on separate ballots in the future), thus, they should all go in separate ballots _now_, it makes no sense to have them all in one ballot where only one can be the winner. I acknowledge that there would be some (extremely unlikely) conflicting outcomes. However, if these unlikely outcomes were to take place, we would have understand that that is actually the position of the project and deal with that sensibly. For example, let's say "Delay Lenny" won and "Allow sourceless firmware" also won. Then, sourceless firmware that is otherwise compatible with the DFSG would be allowed, and no longer an RC bug, but the rest of the licensing issues (if any) would need to be resolved. Or, let's say "Delay Lenny" won and "Allow the RT to decide what to ignore" also won. In this case, the RT would have to acknowledge that the project prefers solving the issues to releasing, and thus shouldn't ignore _those_ issues, but would be able to use the ignore-<...> tags in the future with permission from the project. The other outcomes that I foresee (the more probable outcomes) are not so very conflicting and thus would not require much thought as to what to do with them. As I said yesterday, I hope you can take this into consideration, if you decide to re-do the vote. -- Love, Marga -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
