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

Re: First autoremovals happen in about 8 days

On Tue, 8 Oct 2013 19:36:57 +0000
Bill Allombert <ballombe@debian.org> wrote:

> On Tue, Oct 08, 2013 at 07:58:03AM +0100, Neil Williams wrote:
> > rc-alert has existed for quite some time and it gets the alert in
> > *ahead* of package removal. It alerts users to the real problem -
> > the RC BUG!
> Did you try to run rc-alert recently ?

I ran it during drafting of the reply. I run it before and during every
BSP. I run it intermittently, especially once a release freeze starts.
It's usually the second filter on which RC bugs I think about looking
at. Naturally, the first filter is ones in my own packages, via DDPO.

> The output is totally
> overwhelming for something that is to run on several computers and
> several times by month. 

Compared to the volume of this list? Honestly? The removal email is
large, it contains a long, long list (sadly) of *source* package names
and no matching list of binaries when anyone running a Debian box and
worrying about packages disappearing only actually has a list of
*binaries* to check. rc-alert handles this for you. If the source
package builds a binary not on your system, it excludes it.

The email is fine for it's purpose - alerting maintainers to problems
in their source packages. Alerting others about problems with binary
packages is a different problem with a different solution.

> Most of the bugs are reported against
> important packages that cannot be removed anyway. This do not give
> good clue about packages that could be NMUed with positive effect.

The list of removals has nothing to do with NMUs - that's a job for
rc-alert and UDD. The relevant RC bugs were filed long before the
packages appear in the removal list. There's no need to wait that long,
so scan rc-alert and work on patches in advance of removal if that is
what is the real issue.

> The removal list is much more useful in this regard, if only because
> once a package is removed, the maintainer can hardly complain about a
> NMU.

After removal? If there's going to be an NMU, do it before removal and
save work for the release and ftp teams.
> > The people with the package installed are those most interested in
> > "restoring" the package? Honestly? By restoring, I assume you simply
> > mean "ignore the RC issue - seeing as nobody seems to care to fix
> > it - and give me a broken package so that I don't have to do
> > anything."
> I am not sure how you justify your assumption.
> At least, my assumption is that people using a package are more
> interested by its availabilty that people that do not use it.
> > (A huge thank you to Niels for doing this task - he really does not
> > deserve to be taking all the flak as the messenger.)
> If you refer to my email, then you completly missed its purpose (to
> encourage Niels to continue to post the list of removal to this list).

I didn't miss that at all - notifications on a list with the volumes of
debian-devel are much easier to miss than something which is directly
relevant to what is installed on your own machine. Why scan through
several thousand emails in the -devel folder to find this thread -
especially when the thread contains lots of messages like this which
spend time talking about the reminder procedure and not about the
actual bugs or the packages to be removed.

How do you compare the removal list against the list of installed
packages on each machine? That's just as much work as parsing the
rc-alert output to exclude some packages.

Inventive use of existing rc-alert options may well be able to remove
listings for packages with certain criteria. I'm happy with rc-alert
as-is but if it isn't enough for everyone, I'm sure a patch would be


Neil Williams

Attachment: signature.asc
Description: PGP signature

Reply to: