On Sun, Jun 29, 2008 at 07:51:59PM +0000, Frans Pop wrote:
> 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!
It is what I am doing at least.
> 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.
I'm not the one that removed the package, and I don't know the
rationale behind this removal.
> 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.
This is what I do when I've seen movement from the maintainer, which
is something that tag + pending qualifies for, you can easily find
examples of that, but thanks for the flame anyways.
> 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.
Please, the RC bug list is trivial to find, I've posted it a lot of
time already, and there are tools to at least find the list of RC bugs
that:
* are not fixed in unstable (because we don't remove if it's fixed in
unstable) ;
* are more than 20 days old ;
* are RC.
This list is roughly 120 bugs long, and it's available to anyone[0].
I'm sure it's fairly trivial to intersect this list with a leaf packages
list, and here it is. Knock yourself out.
> 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.
You're sad that we don't (in the release team) know every single
internal piece of d-i ? Well too bad then. I'm glad we have this in
place because now I don't have to worry about a mistake. But I assume
it's easier to be the jerk in the conversation, and completely overlook
the huge task that is doing a good job in the release team. Everyone
expect us to know every single bit of anything that makes Debian works,
and heellooo we don't, because no one humanly can. So we need help. And
yes, the fact that we develop these tools says a lot about the release
management: we care.
On Fri, Jun 27, 2008 at 08:31:24PM +0000, Joey Hess wrote:
> Another case is NTP, which was kicked out of testing for a
> licensing bug, causing much grief to be reported on debian-user.
FWIW I was the one asking the removal: upstream has a fix that is
backportable, not trivially, but that is. And there is openntpd that is
a drop in replacement for most desktop users (and I assume that testing
users aren't really servers, that would need the additionnal features
ntp provides and openntpd has not). Here is my rationale.
Again, like I proposed it before, I'm ready to work with people who
care about testing usability and can focus on bugs that hinder the
release. So far, lot of noise has been made, and the sole new help I've
seen came from lucas.
[0] http://bts.turmzimmer.net/details.php?bydist=both&sortby=srcpackages&ignhinted=on&ignclaimed=on&ignnew=on&ignmerged=on&ignnonfree=on&ignbritney=on&ignotherfixed=on&new=20&refresh=1800
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpUpE3ZAjGJK.pgp
Description: PGP signature