Manoj Srivastava <sriva...@debian.org> writes: > I am not sure how even choice 1 is over riding that decision. Do > you believe that the release team, despite their protestations, is > bundling DFSG violatons into main? If the release team is releasing > only free stuff, then option 1 is being followed. > > I do not see where you get this over ride a delegate bit from, > unless you are accusing the release team of violating the 100 % free > debian system bit. > > Can you clarify?
If you go back to my original message on this, you'll see that I said that *either* option 1 is a delegate override *or* it's meaningless. It sounds like you're arguing (probably just for the sake of discussion) that it's meaningless and we should continue on to release lenny even if it passes. Is that correct? *This* is exactly why I think that the ballot is poorly worded and could have used additional assistance, not in the form of rewriting it, but in the form of someone saying "uh, this makes no sense -- if you want to override a decision, be explicit." I agree that any of us could have offered that assistance, and therefore this is something of a collective failure. There are multiple different ways by which to arrive at the conclusion that releasing lenny as-is doesn't violate the SC. One of them is that points 1 and 4 of the SC are in conflict and we steer a course between the two of them. Another is that the DFSG doesn't apply to firmware now. Another is that the SC is a goal that we don't need to meet in full immediately. Another is that given that the software is already in the archive, whatever problems there are aren't the release team's problem. There are probably others. I've seen all of the above put forward by different people as part of this discussion. I intend to extent to all of my fellow developers the assumption that they hold their opinions sincerely and not deceptively. I can't tell you which interpretation is correct, if any of them -- that's exactly the point under dispute. I can tell you what I personally believe, but that doesn't really mean anything. Other people can arrive at similar conclusions for entirely different reasons. I don't agree with all of those opinions, but that doesn't matter -- that just means that we don't have consensus, and we knew that already. The question now is how do we decide what to do given the lack of consensus. I think it was manifestly clear from the way in which Robert Millan made his proposal and the discussion leading up to it that he intended it to be a delegate decision override, and I think that even in the absence of better wording to make that explicit, the project should treat it accordingly anyway, since that was obviously the intent. >> To some extent, as secretary, you're basically screwed here. Every >> decision that you can make about majority is arguably begging the >> question. > > Hmm. So, in my role as a vote taker, I have to decide on the > majority requirement of every option, and so my daily tasks require > interpretation of the SC/DFSG to see if they are being overridden or > changed. Now, who gets to interpret that SC/DFSG? perhaps what follows > may shed some light. Except that then you end up in the situation we're in now, where an option that is functionally equivalent to further discussion gets a 3:1 majority requirement because you don't agree with the delegate decision, and I don't think that's a good place to be. That's why I'm trying to offer a proposal for how the secretary can decide a majority requirement when the question of a majority requirement is exactly what is under dispute. I think that would be worthwhile because I think it gets us a more workable decision-making process that's still consistent with the constitution. Otherwise, we can get into a situation where a strong disagreement between a delegate and the secretary on an issue where the project does not have a 3:1 majority either way results in a ballot that cannot decide the topic, because no one agrees about whether a majority vote sufficiently decides a question. > Wonderful. The delegate, or the role in charge, decodes how to > interpret the DFSG and the SC in their day to day work. > > All we have to do is decide who the role in charge is that > decodes how the DFSG and SC is to be interpreted when deciding of the > procedures and form of the ballot in a vote. > > Right? No, I think this is too simplistic. A vote is not solely your work as secretary. It also has a direct effect on other people's work. It's effectively part of multiple decision-making processes at the same time. > Now, we are saying that we are giving away the decisions to > decide about violations of the social contract with respect to the > Debian system to a handful of developers. The constitution says that, by not creating any special status or separate decision-making process for disputes over interpretations and application of foundation documents. We therefore did that when we adopted the constitution. Those decisions can, of course, be overturned by GR. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
