Re: where to leave info about "bad packages" (in the bapase sense)
Lucas Nussbaum wrote:
> 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?
Hi folks,
Sorry for jumping in late here but as someone who does quite a few
removals/orphans/etc how is this much different than the current process? (Other
than moving bapase to collab-maint.
Also, just out of curiosity, why 50 days? Seems like a strange number. Also do
you think there will be enough interest to warrant another mailing address?
Thanks!
Barry deFreese
Reply to: