[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: where to leave info about "bad packages" (in the bapase sense)



On 04/12/09 at 09:37 +0100, Stefano Zacchiroli wrote:
> On Thu, Dec 03, 2009 at 01:38:42PM +0100, Lucas Nussbaum wrote:
> > Why do you want to duplicate the information between bapase and the
> > usertags? I find it quite hard to use usertags to following such complex
> > information.
> 
> I got convinced recently that we should be more aggressive about removal
> requests, also I don't think that such an activity should remain
> confined under the "QA hat". Hence I'm trying to make the process more
> distributed: as every DD can make an NMU, IMO every DD should feel free
> to propose the removal of a crappy package. The process I tried to
> summarize is an attempt in that direction.
> 
> Now, I don't want to interfere with the bapase workflow (BTW, is bapase
> regularly running? the report link from the wiki was 404 yesterday), but
> it surely is not accessible to every DD, since you need commit access to
> collab-qa.

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).

OK. Let's start again.

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.
 
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)

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
- wait for at least 50 days, listen to comments made on the bug report
- request the removal (if appropriate) of the package by reassigning
  the bug to ftp.debian.org

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
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.

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 additional email alias
@qa.debian.org.

Comments?
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |


Reply to: