That is the sledgehammer argument people bring up when others dare to criticize the current release process.
I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, it looks like in this release we simply started the freeze with much more open RC-bugs than before (~3 times more RC-bugs than with Etch). So it was foreseeable that the freeze would take longer this time. We can’t solve the problem by trying to fix bugs faster, we’ve tried it several times with mediocre success. That doesn’t mean we shouldn’t keep up fixing bugs, but we should probably accept that a certain number of people can only fix a certain number of bugs in a given time. In our case roughly 30 RC-bugs per month.
So what’s the point of asking how many RC-bugs one has fixed? Does that mean only those are allowed to make suggestions, who fixed an RC bug? That pressure doesn’t help anyone. I believe unstable being frozen for several months is a very important problem which can have drastic consequences regarding the number of our users, and we will not solve it by suggesting to fix our bugs faster.
I agree, this vote is one of the worst formulated I can remember. I think votes should be as easy as possible to understand, so that the voter is absolutely clear about what he’s going to vote. The current vote is the perfect example how not to design such a vote. Reading and understanding the ballot is very exhausting, the wording sounds polemic and given the options, it somehow feels like a trap.
Example: The first option is “Reaffirm the social contract”. Sounds nice, of course we want that, but in the footnotes it says
[...] we will delay the release of Lenny until such point that the work to free the operating system is complete (to the best of our knowledge as of 1 November 2008).
So you’re actually voting on delaying the release of Lenny until some technical details are cleared. This is really crap, why not name the option “Delay Lenny until foo” in the first place? I guess to motivate people a bit more to rank this option above all others.
I’m very disappointed. Next vote, fever options and clearer wording please.
Two months since my last status update of my initial guess for Lenny’s release date, time for an update:
I don’t know what the current “official” release target for Lenny is, but I still think we’re heading towards Spring/Summer 2009.
The last related mail on -devel-announce is from October 2008 from Alexander who hopes that we’ll release Lenny at least by the end of 2008. I’ve read an article with an interview with Steve McIntyre somewhere on The Register where he said:
“Bastian’s being a little bit pessimistic based on the data he’s looking at, but as far as I know, he hasn’t spoken to any of the release team. As far as Lenny goes, we’re ‘almost’ there,” he told The Register.
That interview was in the beginning of October.
It doesn’t bother me too much, that we release late. What bothers me is that we don’t correct our estimated release dates even when it’s obvious that there is no way we will release in time. It’s really sad that we keep our users in the dark about the fact that we can’t release in time until it’s already too late.
I believe many users would appreciate if we’d honestly say: We don’t know when we release, but currently we have x RC bugs open and looking at the last releases we think it will take roughly n months to fix them and release, instead of the good old “We release when it’s ready”.
Another important point: Unstable is frozen for almost five months now. If you buy a current laptop, chances are hight that it might not fully work with Debian “bleeding edge” unstable, since it’s horrible outdated. Some of the newer stuff can be obtained from experimental if you’re brave enough, but if you’re not, unstable is getting more and more unattractive compared to other distribution’s current versions. This is really something we should try to fix after we released Lenny.