[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Num closed vs. num opened RC bugs



Hello,

First of all, I must say that I am only a Debian user, maybe we may say an "active" user, because I submit bugs and I have sometimes written to this list to request binNMUs. I mean, I am neither a developer nor do I help in maintenance tasks, because I lack the programming skills (I do wish I would have those skills :-)  ).

That said, I think I can still raise an issue that is easy to spot even for non-developers. According to http://bugs.debian.org/release-critical/, each day 1,2 or 3 RC bugs get closed and more than 30 new are opened. In the last couple of days, the "Number concerning the next release" has increased in around 20. I think it is evident that *we cannot allow ourselves the luxury of doing nothing (I mean "nothing" to tackle this problem) and just wait*. I do not really have much hope that lenny is ready by next Summer, but, if the number of opened and closed RC bugs continues like that, lenny will never be relased. Just basic mathematics :-) Furthermore, *this freeze is "suffered" by all users*: of stable, of testing and of sid. And, as I am in a productive environment, I will not activate experimental.

Maybe I can think of little invasive, but very efficient, strategies: one of them could be to *"freeze" the bug tracking system* and make it not accept automatically new RC bugs. Such new RC bugs might be manually approved or rejected by the maintainer. At the end of the day, the worst possible scenario is that lenny is released with a few RC bugs, which will happen in any case (see the number of RC bugs that etch "gained" after it was released).

This is just an idea, maybe you experienced developers can give some more ideas. But it is clear, because of the balance closed-open RC bugs per day, that we must do something if we want to release lenny before our grandchildren die :-D

Please Cc to me if someone cotinues this thread.

Thank you very much,

David

Reply to: