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.
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.
> - 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.
> - 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?
> 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 ...
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.
> 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.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature