On Friday 27 June 2008, Pierre Habouzit wrote: > Well, the thing is, we have quite a clear policy, which is to remove > (not in period of a freeze of course) packages that are: > * leaf packages ; > * RC buggy ; > * for more than 20 days ; > * with absolutely no movement from the maintainer.
But that is not what you are doing! Let's take resolvconf as example (rather randomly: just because it was mentioned on d-devel). - It is listed at rank ~2200 in popcon's "installed", but at 854 in the "vote" column, which means it is a rather popular package. It may _technically_ be a leaf package, but it is obviously an important package to *our users*. - Another reason this is not just "any leaf package" is that it is referenced in the bind9 postinst script (or is bind9 an unimportant leaf package too?). - The RC bug that caused the removal (#477752) was filed on 25 Apr and it was fixed in VCS *the next day*, and tagged pending. How the hell does that qualify as "absolutely no movement from the maintainer"? - IMO the RC bug in itself, although technically RC, does not affect the usability of the package sufficiently to justify removal from testing. IMO a "responsible" Release Manager would have sent a friendly reminder to the maintainers to please upload the pending fix. My guess is however that the RM never even looked at the BR, but just blindly ran some "remove buggy packages from testing" script. The same goes for the removal from testing before D-I Beta1 of loop-aes, which caused a huge amount of unnecessary work and contributed significantly to the delay of our release (and despite all the work it ended up being an erratum because it was never accepted from t-p-u). I also feel the current removal policy is counter-productive. Why? Because it _reduces_ the visibility of RC bugs rather than increasing it. Only very few people get informed of which particular packages are removed from testing, and the relevant bugs then drop of lists that active bug squashers use to select issues to work on. IMO Steve's suggestion makes a huge amount of sense because his proposal would actually raise awareness of RC issues that need help. It's a huge pity that you just reject it out of hand. > Note that less than a week after having been removed, mplayer and > lilo have been fixed. It's fun to see how easy it is to fix > "unsolvable" bugs with the proper incentive. I'm glad that you're having "fun". I personally find it very unfunny when I have to waste my time answering mails from users like: http://lists.debian.org/debian-cd/2008/06/msg00036.html I'm very grateful to Adeodato for the work he's done on getting the "do not remove" functionality implemented, but it is extremely sad that that functionality is needed at all. IMO the fact that it _is_ needed says a lot about the quality of the current "release management" effort. Unfortunately your whole response still shows a complete lack of recognition of what the current RT "policy" does for the motivation of other Debian Developers. I am finding that over the past months my motivation to work towards the Lenny release is growing less and less, and I'm now very sad to say it has reached about zero. And in a large part that is due to the attitude of the release team (a few individuals excepted). I hope you have fun force-releasing Lenny at the planned date instead of working with your fellow developers to release Lenny "when it's ready" (with the planned date as target) and at the quality level our users expect from Debian, but I'm getting off this train. Cheers, FJP
signature.asc
Description: This is a digitally signed message part.
