Re: The Unofficial (and Very Simple) Lenny GR: call for votes
* Frans Pop [Mon, 15 Dec 2008 20:09:28 +0100]:
> > * Frans Pop [Mon, 15 Dec 2008 18:23:00 +0100]:
> > > How does this help? The only effect of voting FD on the official vote
> > > is to play into the hands of those who don't want any firmware
> > > support in Debian.
> > That is not true, as it is (hopefully clearly enough) explained in the
> > mail you replied to, section "On ranking FD first in the official
> > vote".
> Because any votes below FD do not count toward quorum/majority. Of course
> you can do all kinds of unofficial analysis on the outcome of the vote
> to "correct" for that, but that does not actually change the official
> outcome of the vote.
You said, "The only effect of voting FD on the official vote is to play
into the hands of those who don't want any firmware support in Debian."
From that, I take that you mean, "if people rank FD first, option #1
Then, or you haven't read the section that I mentioned, or you are
ignoring it, or the wording of that section is not clear enough.
Sadly, I don't have the energy to rephrase the whole section to make it
clearer. If you can explain why voting FD/5/1 instead of 5/FD/1 is going
to make option #1 win, clearly stating which parts of my explanations in
the mentioned section you believe to be false, then we may get somewhere.
> > > I don't like either of these choices. So what do I do now?
> > You don't vote, or you vote 11, or you raise your concerns, or you go
> > for a walk.
> Voting 11 does not reflect my position, I am raising my concerns and I
> feel this is too important to just take a walk.
> > Is up to you, really, because I did the best I could, but it's
> > impossible to please everybody.
> The reason why we have the option to propose amendments for official votes
> is exactly to make sure that "everybody gets pleased", or at least that
> all opinions that have sufficient support within the project are
> reflected on the balot. That is why your poll is an even greater farce
> then the official vote.
You can see where the ability to propose amendments, in combination with
the current Secretary, has lead us to. But then, I didn't think there
was time for a whole propose & discuss period, since I prioritized
getting as much voting time as possible for this unofficial vote.
You may think this has converted the unofficial vote in a farce. I won't
be able to convince you of the contrary, so let's agree to disagree.
* * *
(I'm now going to swap the order of two of your paragraphs, because I
think it is better. Hope it doesn't cause any inconvenience.)
> > > I very much don't want option 2, but option 1 would mean sanctioning
> > > the RT, which I very much also don't want to do. The official vote at
> > > least _does_ allow me to express my opinion.
> > Hm. Can you ellaborate on what you mean by "sanctioning the RT". If you
> > mean to imply that option #1 in the unofficial vote inadvertently says
that's a 2, of course
> > "RT should have the right for <suite>-ignore tags always, no matter
> > what", that wasn't the intention and I don't think it says that.
> See above. I really don't see how else the text for option 2 can be
> interpreted. It may not be the main purpose of the text, but IMO it is
> definitely implied.
I strongly disagree that it is even remotely implied. The wording of the
option talks about the lenny-ignore tags that the release team **has**
aplied, not from what it may do in the future.
However, you make a different and quite valid point with:
> > If it is important to you that the release team doesn't use
> > <suite>-ignore tags on bugs regarding DFSG compliance, then go for it:
> > propose a GR, and let's vote on it (I repeated this idea in the
> > "Unofficial GR" mail, too).
> No sorry, that is unacceptable. Your poll makes the same mistake the
> official vote does: it mixes separate issues into a single vote. And it
> is worse because it does not even allow to express preferences among
> those issues.
> The poll would have been a lot more acceptable if the second option had
> been worded simply to "accept the same exception regarding DFSG
> violations for firmware that was made for Sarge and Etch". By adding in
> the issue of "use of tags by the RT" you _are_ effectively adding in a
> sanction of how the RT has handled this whole issue.
I read these two paragraphs carefully, sat on them for a while, and I
got what you mean: the poll does not give an option for people who were
discontent, *not with the direction in which the tags were applied
(leave firmware in Lenny), but with the tags being applied for these
issues without consultation*.
And you'll have to excuse this mistake, because since in my head the
person who most complained about the use of the tags without
consultation was Robert Millan, who *also* disagreed (apparently?) in
the direction the tags were applied, I sort of associated the two in my
In other words: yes, when writing the options of the unofficial vote, I
had a limited view of the world by thinking that everybody who wouldn't
want lenny delayed, wouldn't have been opposed to the tags in the first
Said that, I hope you'll reckon this wasn't done purposely, and that my
mistake is understandable because I haven't seen much strong opposition
to our usage of the tags by people who didn't opose to the direction of
the tag as well. (When I say that I haven't seen much opposition, I mean
that I can only recall you doing so, but my memory could be failing on
me and I'll happily stand corrected.)
* * *
> > My opinion is that the release team should have the right to that use
> > of <suite>-ignore tags, and then get overriden by a GR on a
> > case-by-case basis, when people feel the tags have ben misused. But if
> > developers show they don't want for it to work that way, then it is for
> > us to accept that and move on, period.
> That is a valid opinion, but IMO it is also completely unworkable. Would
> you really want (the possibility of) a GR for every single case where
> someone feels a tag is not used correctly?
Would you really want (the certainty of) a GR for every time where the
release team wants to use a <suite>-ignore tag for a licensing issue?
* * *
> > > IMO we _do_ need the current vote, only it should not have been
> > > contaminated with the options re. the release team powers and re.
> > > source requirement for firmware. Those issues should IMO have been
> > > handled as separate GRs _after_ the question what to do for Lenny had
> > > been settled.
> > Fully agreed. (Though up to the first comma, I agree because there was
> > an effort by a number of developers who wanted this vote to happen, not
> > becaue it was needed "no matter what", see above. But that way of
> > thinking can of course change via a "release team powers" GR, to use
> > your own words.)
> Which will probably be after the release team has released Lenny, ignoring
> the outcome of an official vote and feeling justified in doing the
> release based on a biased poll? Please tell me that's not true...
It is not true that the release team is going to base the delaying or
not of Lenny on the results of the unofficial poll, nor ignore the
outcome of the official GR. The latest release update says:
| If this GR were to prove us wrong, we'd suck it up, stand corrected,
| and come with a plan that doesn't involve ignoring the outcome of the
That "GR" obviously refers to the official one (heck, when I wrote those
words I hadn't even thought of running an unofficial vote). Do you need
> But I'm afraid it very much looks like that's exactly what the intention
> is. Take the following sentence from your mail:
> "[...] it may also give us a good approximation about what the developers
> think with respect to releasing Lenny."
> This mentions "us" versus "developers". So "us" cannot be "the Debian
> project". Only conclusion can be that "us" is the release team,
> especially given that one of its members is running the poll.
Meh, that's unfortunate. It's more unfortunate because the text "Without
any hats" was written at some point in my mail.
To make things clear: this unofficial vote was started by me as an
individual developer *out of frustration with the current ballot*, and
*not* because I thought it was needed to ensure that I can proceed with
my plans for Lenny the way I want them to happen. It wasn't coordinated
with the rest of the release team, but with other developers that felt
the same way as me about the ballot.
> > > Thanks for increasing the mess we already have. I will personally
> > > ignore this additional "vote" which suffers from the same problem as
> > > the "official" one, namely that it is unacceptably colored by the
> > > person who is managing it.
> > Peace to you too.
> I hereby request you to abandon this poll and to route any "votes"
> to /dev/null. As mentioned in my original mail and argued there and above
> I really do think this makes an even bigger travesty of Debian's
> democratic process then the official vote.
> Abandoning the poll would of course nullify my objection to the DPL.
Well, you'll have to understand that I'm not going to stop doing
something which I don't believe to be wrong just because a fellow
developer asks me to.
If more people do share your concerns, though, maybe abandoning the poll
would be the right thing. If it's only you, I can't but offer all my
explanations above, assert that they're true, and hope they can bring us
* * *
One final thing: these two mails of you have brought a fair amount of
stress on me, because of the way you say things. (Maybe you don't feel
it's reasonable for me to feel stressed, but it's simply true that I
I have swallowed hard and replied calmly to them, because I believe
developers, and particularly those holding key positions, should not
ignore other developers, even if their concerns don't come in with a
wrapping of sugar. (I don't want to ignore people in my Debian work, and
if it ends up being impossible to deal with somebody, I'll clearly let
However, the same way I've made an exercise and considered your views on
actions of mine that I felt were right, I'm going to invite you make an
exercise and consider what your style may bring onto other fellow
developers (even if your points are right), because I know you've felt
stressed with interactions with other developers yourself in the past,
and it'd be bad to bring to others what you so much loathed.
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Vainica Doble - Quiero tu nombre olvidar