Dear all, sorry also for jumping late in the thread. I have a couple of comments as a person quite new in the field of package removals (two this year).
First of all, I was much shyed by reportbug: aqwa『~』$ reportbug ftp.debian.org *** Welcome to reportbug. Use ? for help at prompts. *** Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Charles Plessy <ple...@debian.org>' as your from address. Getting status for ftp.debian.org... Will send report to Debian (per lsb_release). What sort of request is this? (If none of these things mean anything to you, or you are trying to report a bug in an existing package, please press Enter to exit reportbug.) 1 ANAIS Package removal - Architecture Not Allowed In Source. 2 ICE Package removal - Internal Compiler Error. 3 NBS Package removal - Not Built [by] Source. 4 NPOASR Package removal - Never Part Of A Stable Release. 5 NVIU Package removal - Newer Version In Unstable. 6 ROM Package removal - Request Of Maintainer. 7 ROP Package removal - Request of Porter. 8 ROSRM Package removal - Request of Stable Release Manager. 9 RoQA Package removal - Requested by the QA team. 10 other Not a package removal request, report other problems. As you can see, there is no option for “Request by simple developer”. Actually, it may be a good filter to avoid that people directly poke the FTP team without making sure that there is consensus for the removal. This is why I like a workflow that starts by a bug on the package. Similarly, for the severity, using “Serious” from the beginning spends more Debian volunteer time than a non-RC severity. For instance, in the case of a NMU to close a RC bug, it would not make sense to open a new RC bug to document concerns on the future of the package, since the package would then stay in the radar of people dedicating time to prepare the next release. I (re?)discovered bapase in this thread, and to me it really seems that both tools are complementary. Bapase has basically only a couple of lines of text to store information, while the BTS can hold much more. I think that typically, a proposition for removal would contain a summary about the activity of the maintainer and upstream, as well as an inspection of the neighbour nodes in the package dependancy network. From my experience of privately inspecting packages for which a NMU sponsor is looked for on debian-mentors, it is not uncommon that although a package looks difficult to remove because it has reverse dependancies, these reverse dependancies are themselves good candidates for removal, typically because they were maintained by the same MIA developer. As discussed in this thread, there needs a couple of incentives to let people insert entries in bapase. Commit facilities, like a good Alioth ACL, and a checkout alias like ‘bapase-checkout’ or ‘debcheckout bapase’ if there would be some good reason to create a bapase binary debian package. In addition, a good advertisement like the improved wiki page written by Stefano. I actually think that once it is stabilised, it would really belong to the Developers Reference. This would help to bridge the NMU workflow and the removal workflow, by inserting a cross-reference to the removal section in the NMU section, suggesting to the NMUers to archive in the BTS the result of the research they made when they decided if the package was worth working on or not, and to register the bug in bapase. If you like the idea, I can keep on following the thread and the wiki page, and propose a patch to the Developers Reference when things are stabilised. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
