This vote is a joke. It mixes very different questions, among them:

• do we trust our release team ;
• shall we delay the Lenny release for firmware issues or not (We answered that twice in the past with huge majorities btw) ;
• shall we modify the meaning the the SC/DFSG.

And you're supposed to make one single option win. Not all options deal with those three questions at once. So definitely, like Julien states it: It's a TRAP.

That's why there is one and only one winning stategy to that vote:

• rank (like Christian did) Further Discussion first.
• rank all the answers to the previous questions at the same level 2 (e.g. for me it's probably option 2 and 4 or something similar).
• do not rank the rest (or rank it 3 or greater or - or whatever).

This vote is a perversion of our voting system, don't fall for it.

Edit (answer to Neil):

Neil, you don't get it, if you make anything else than Further Discussion win, you actually let one option of the vote win. As most of the ballot options only answer at most 2 of the underlying questions I cited above, and only one for many of the options, you give the power to the secretary to decide what the option you voted for meant. This is unacceptable, therefore, you have to put further discussion first. We just don't want to let one single man (that showed that he's totally unable to prepare a sane vote, without pushing his agenda at the same time) decide the real issue of the vote.

With firefox3 entering unstable, it's now possible to upload firefox3 extensions.

Vimperator just entered unstable tonight, just enjoy it. For those not knowing about it, it's an excellent extension that gives to your firefox the vim look and feel. People that are already hooked to git will love it. Tiled window manager users usually love it.

The best feature it has is the so called “quick hints” feature. Type f in command mode, to have nice labels next to every link in the page. You can type some letter, and only links that contains those letters will have the hints, and you'll see something like this (I added 'mo' after having asked for quick hints like you can see in the ruler):

Dear Bastian let's fix your blog post.

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.

s/Philipp/the Release Team/g. And yes, we believe that reportbug-ng goes against the Maintainers wishes, and doesn't help users that don't know how to report a bug (and which are rng audience unless I'm mistaken).

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.

It's not, it was discussed in the Release Team and was not Philipp on his own alone. And yes, the same standards of quality is wanted for every package in Debian.

I mean, rng has no release critical defects.

That's you claiming that, there have been really constructive remarks in both bug that we upgraded, and that I think explain wisely why the current reportbug-ng behaviour doesn't makes it a suitable reportbug tool right now. I think for example that Sam's and Michael Biebl contributions in both bugs are good explanations of what is wrong and why.

It just does not use the aforementioned scripts as additional information in bugreports — does this really render the software “unfit for release”?

Yes it does. Again, people that use rng are I think, less experienced users, who need guidance through the bug reporting process. The kind of users that often send annoying bug reports. Instead of lowering the annoyance factor, you aggravate it. In the end, rng makes the frustration higher, and totally fails to meet its primary goals: making bug reporting nicer, simpler, and more efficient for the Reporter and the Maintainer. While it's probably nicer for the reporter, you totally fail on the other part of the contract. And if you don't care about the Maintainer, then well, reportbug-ng is just a spam machine to them, and your careless attitude toward them is “unfit for release” for sure.

Today is again about removing packages from testing as my hintfile says. We've discussed (in the RM team) policy a bit, and it seems that we agree that packages with Release Critical bugs open for more than 3 weeks without any kind of activity from the Maintainer warrant a removal from testing without prior notification. Tonight's work is then just doing the quite not fascinating work of going through this list and look for removal candidates.

Note that we will always give more time to Maintainers that need it to fix a bug, if he/she states so in the bug report. Needing time is perfectly okay. Not telling about it isn't.

Paid work burnt all my free time recenlty, that's why there wasn't a rc-bug-a-day for two days. I'm back with two removals, a couple of gcc-4.3 FTBFSes fixed. And 5 uploads for RG bugs from Sandro Tosi that were rotting in my mail client.

The bad news for tonight is that gcc-4.3 FTBFSes are now RC, since it's the default compiler on several architectures. That's almost 40 new RC we now have to deal with. The fun part will be that those RC will probably hinder some transitions to testing. Maintainers, please, fix your packages. There are still too many packages with RG bugs on them, open for many days, from maintainer that are otherwise quite active on IRC or the lists…

Today's RC bug was 470462, removal of a package that as a patch for a FTBFS and absolutely no maintainer answers (#417047).

I'm also quite excited because I have a mail with 9 nmudiff's for RG/RC bugs waiting to be processed from Sandro Tosi. I want MOAR !

There was no RC-Bug-A-Day yesterday, so two RC bugs for today:

• #463094 some missing ${subst:Stuff} in a debian/control;
• #456864 some other missing Build-Dependency causing a FTBFS.

I also plan to sponsor the requests piling in my @debian.org mailbox tonight too.

For today, a debian/copyright bug in tct was fixed.

Today's paid work ate all my time, so my RC/RG bug squashing was only made of uploading other's work.

Thanks again to Kartik and Kumar.

Today saw the removal (from testing) of:

• syslog-ng that has a really grave bug (loss of logs when the daemon is signaled with a SIGHUP) that is fixed-upstream for quite a while;
• w3c-libwww that the maintainer would like to get rid of, that had two RC. Sadly, I had to remove wmweather+ (its sole r-dep in lenny) that the maintainer still hasn't fixed, but it should be temporary.

All in all, that's 5 RC bugs that aren't in lenny anymore.

Note: I've been pretty busy today, I've seen mails to ask NMU sponsoring for RC/RG bugs, I will have a look, don't worry.

For today, 464893 was downgraded partly because gksu works fine for me for a long time, hence critical was completely overestimated, and partly because no matter how hard I try to reproduce the bug I can't. If you do, please follow up on the bug log.

Also, a new sponsored NMU for gnomesword (bug#461959), thanks to Kumar again :)

Today's work:

• I sponsored one more NMU from Kumar Appaiah for 454829.
• I also closed 458659 that wasn't reproducible, hence probably fixed in 5.7012-4 or 5.7012-5.