Re: First call for votes for the Lenny release GR
Manoj Srivastava <srivasta@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: