Re: where to leave info about "bad packages" (in the bapase sense)
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 <plessy@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
Reply to: