On Tue, 8 Oct 2013 19:36:57 +0000 Bill Allombert <ballo...@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 useful. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
