Today Lenny was finally released. According to this page with roughly 120 open release critical bugs. That’s quite a big number according to our standards, but still a good and necessary compromise. Thanks for everyone involved, good work everyone!
I’m very happy that the release didn’t take quite as long as I predicted. Three or four more months of Sid being frozen would probably have meant more people playing with semi-supported mixtures of unstable and experimental packages and more migration towards other distributions with more current software packages. So I’m very happy to see over a hundred new packages uploaded to unstable already and roughly 700 new release critical bugs opened
According to this message on -devel-announce, Lenny might release on this year’s Valentine’s Day which happens to be in two weeks.
These are absolutely fantastic news! Can’t wait to comment out the experimental lines in my sources.list and see some fresh (and badly needed) packages in unstable again.
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.
Today, an article at heise online claimed, that Lenny is supposed to ship this year, quoting Alexander’s blog entry. While I can’t find a single word in Alexander’s article claiming that we’ll release this year, I’m pretty sorry that just after we failed the first deadline which was obviously too “optimistic”, we get another one which is too short.
Two month’s ago I created a pretty simple estimation regarding Lenny’s release by looking at the rc-bugfix-rate of the last two releases and applying them to the current number of rc-bugs. As a result it looked more likely that we release Lenny in June 2009 than in September 2008. Until now, my guess for Lenny’s release still holds, at least the updated rc-graph lies perfectly on the line I’ve created two months ago.
While I wish that we’ll release Lenny as soon as possible, I hope that someone will clarify the proposed release date to the media and this time with a more defensive deadline. Some people might actually trust our estimation (I know this sounds silly). And even if everyone knows that Debian notoriously releases too late — we could at least try to propose more realistic dates and update them regularly. Just two weeks ago I still read and heard in the media that Debian will release Lenny in September although it was clear at this point that this is impossible.
Looking at the current number of release-critical bugs, my guess for the actual release date of Lenny is: around June 2009.
The blue lines have exactly the same angle, the greenish line marks the planned release date.
I know that’s not exactly scientific, but let’s see how close I am.
The blue graph marks by the way the number of release-critical bugs in stable.
Philipp thinks, the fact that rng is not using the information in /usr/share/bug renders rng “unfit for release” and upgraded the corresponding bugreport from wishlist to serious. Moreover: since I dared to downgrade the report back to wishlist he decided to remove rng from testing and block it until the bug is fixed.
I don’t want to heat the debate about this bug again, but Philipp’s decision seems arbitrary for me and I wonder if the same standard is applied to every other Debian package. I mean, rng has no release critical defects. It just does not use the aforementioned scripts as additional information in bugreports — does this really render the software “unfit for release”? For example: In Etch we shipped a famous email client with a known bug which lead reproducibly to loss of emails on IMAP accounts, just because removing the program, or one of it’s components was not possible in the remaining time.