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

Re: Testing removal policy (was: Mechanism in place...)



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

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: