Re: where to leave info about "bad packages" (in the bapase sense)
On 06/12/09 at 17:27 +0100, Stefano Zacchiroli wrote:
> Heya, sorry for the late reply.
>
> On Fri, Dec 04, 2009 at 10:52:27AM +0100, Lucas Nussbaum wrote:
> > We could move the .txt file to collab-maint.
> > The way it works is that the CGI at
> > http://udd.debian.org/cgi-bin/bapase.cgi does a "svn cat" of the file in
> > collab-qa to get its information, so it doesn't need to be regularly
> > running (as in cron job).
>
> That would be fine by me, but I hope you'd agree that for the average
> contributor it would still be less handy than simply interacting with
> the BTS as she probably does several times a week.
>
> > Problem statement:
> > There are some packages in Debian that should be removed from it,
> > because they have become useless, have better alternatives
> > in Debian, do not bring enough value (e.g 10-lines shell scripts).
> > There are also packages who should be kept in Debian, but which were
> > abandonned by their maintainer(s), and should be orphaned so another
> > maintainer can pick them up.
>
> ACK.
>
> > Requirements:
> > (1) process to propose and proceed with the removal of packages
> > from Debian, even when the maintainer is unreachable
> > (2) process to propose and proceed with the orphanage of packages
> > in Debian, even when the maintainer is unreachable
> > (3) public processes, to provide effective public review
> > (4) efficient processes (we are talking about 500+ packages)
>
> ACK.
>
> > Proposed process (based on the proposal made in this thread):
> > When someone wants to propose the removal of a package, he/she:
> > - file a bug on the package, explaining the reasons
> > + severity: serious (if the package is something we want to remove,
> > it's not something we want in the next stable release anyway)
> > + usertagged debian-qa@lists.debian.org / proposed-removal
>
> Note: thus far you've been talking a joint/similar process for
> removals/orphaning, from here on you only consider removing. That's fine
> by me since it was the problem I was mostly concerned with :-), but
> there are differences.
>
> For instance, while severity "serious" is OK for removing for the
> reasons you mention, it is probably unapproriate for orphaning as we've
> never taken the decision of considering RC all packages without a
> maintainer. Aside, let's try not discussing the two decisions together
> as they are quite orthogonal.
OK
> Also, I'd add above the explicit requirement of Cc-ing debian-qa@l.d.o
> upon bug submission or initial proposed-removal tagging. Rationale:
> since the final request will be marked RoQA, we should better be
> informed of that. If there is a fear of SPAMming this list, we can spin
> off a new list for such notifications.
OK
> > - wait for at least 50 days, listen to comments made on the bug report
>
> Why? It is definitely too much.
>
> The main problem with this is that it assumes the package is worth
> removing from the moment it gets bugged, whereas it could have been
> worth removing since ever. This is even more true now that we start with
> the process from scratch. One can stumble upon a package that is worth
> being removed since various releases, I don't think we should wait for
> about 2 months in those cases.
>
> The only purpose of the delay here is letting the maintainer react. I
> would hence take a delay like the largest we have for DELAYED NMU, since
> it is a good approximation of what we consider maximum acceptable
> maintainer reaction time. According to devref §5.11.1, such delay is 10
> days.
50 days might be too much, but 10 days (in the general case) is
definitely too short. I agree that there might be cases where waiting 10
days is appropriate. But using 10 days by default will allow for many
packages to be removed by mistake. I would prefer if it was recommended
to choose a delay between 10 and 30 days, with 30 days being the
default.
We have often had those packages in the archive for years, so 20 more
days is not a big issue. If it is, then the problem might be with the
tools we have to track those removals, not with the removals themselves.
> > - request the removal (if appropriate) of the package by reassigning
> > the bug to ftp.debian.org
>
> ACK.
>
> > Additionally, bapase (http://udd.debian.org/cgi-bin/bapase.cgi) is used
> > to track packages in that process. It provides an easy way to:
> > - find packages that have been through the 50-days delay
> > - find "interesting" packages, based on various criterias
>
> I agree with this, but what we really want is an monitoring tool that
> when the period is elapsed automatically reassign bugs to ftp.d.o. We
> have similar monitors for other BTS activities such as automatic closure
> of long outstanding ITP bugs. Can bapase provide that?
No, please don't! We really want to review the bugs again before asking
for removal. Many people have been unhappy with the ITA/ITP retitler
because it was changing the state of bugs they were actively working on.
Here, we are talking about decisions that are much more important.
[ or, we could start by not doing automated reassignings, and revisit
this in 6 months if we really think that it's stupid to do it manually ]
> > It uses a text file with more information than what can be easily provided
> > via usertags, so:
> > - people who propose a lot of removals are encouraged to add information
> > to bapase directly
> > - a way to list packages that have had proposed-removal bugs filed, but
> > are not tracked in bapase, is added to bapase.
>
> Can you expand these two? I'm not sure I understand them ...
OK. A bapase entry looks like:
skippy 2007-09-30 lucas PROP_RM(444715)
skippy 2007-11-29 lucas WAIT(15)
skippy 2007-12-18 lucas PROP_RM_O(444715)
skippy 2008-01-10 lucas REQ_RM(444715)
The main problem with using only usertags is that we would have to come
up with a complex title format to track:
- when the removal was proposed (might be different from "when the bug
was filed" in case an existing bug is reused)
- if an additional grace period was allowed (example case:
+ package is horribly broken, someone notices and proposes removal
+ maintainer says he will work on this, but is terribly busy. asks to
wait for 2 months
=> in that case, we want to store something like "this should
probably be removed, but let's wait for two months before revisiting
this package")
Instead of tracking this via a specific title format, it sounds easier
to track this in bapase. Also, it prevents maintainers from retitling
the bug by mistake, causing the loss of that information.
But I understand that some people don't want to invest time in bapase,
and prefer just to file bugs. So I propose to improve bapase with a way
to list packages with proposed-removal bugs, that are not currently
tracked in bapase. That way, bapase-interested people could add
information to bapase about those packages.
Basically, this boils down to: "you don't want to care about bapase?
Just file the bugs and usertag them, someone might add them to bapase
for you".
> To me, the main utility of bapase would be to help people that do not
> just stumble occasionally on a package worth removing (like NMUers), but
> want to actively work in identifying packages worth removing. They use
> bapase as their work tool; the outcome of that tool is filing/tagging
> the proposed-removal bug.
Well, that's only half of what bapase does. The other half is the
tracking of proposed removals, to be able to process a large amount of
removals concurrently.
> > Problem not addressed: we probably need a way for people to report
> > packages that probably need removal. People might not want to do the
> > process themselves. This could be with an additinal email alias
> > @qa.debian.org.
>
> Yes, and with a bit of discipline in reports (e.g. a fixed format), we
> can have those entries automatically become bapase metadata.
If you really want to push for that, a good start would be to propose a
fixed format that stores what is currently relevant in bapase. It would
have to be stored directly using usertags, or in the bug title (UDD and
other tools don't store the full bug log, so using pseudo-headers
in bug messages would not work).
See http://svn.debian.org/wsvn/collab-qa/bapase/README for the
description of the various tags, and
http://svn.debian.org/wsvn/collab-qa/bapase/package-actions.txt for the
list of (package, action).
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: