On 03/12/09 at 10:58 +0100, Stefano Zacchiroli wrote: > On Thu, Dec 03, 2009 at 10:23:57AM +0100, Lucas Nussbaum wrote: > > I would prefer to track the info at the two places. In bapase, we also > > store the date the removal was proposed, to be able to list packages by > > date of proposed removal (it makes sense to wait for a while before > > removing the package, and it's difficult to track that manually or using > > the BTS). > > I'm not very convinced by the arguments, but OK, if it makes the bapase > workflow easier than we can live with that. > > Still, can we at least confirm the workflow which is now detailed in the > wiki page, so that there is never a proposed orphan/remove in bapase and > not in the BTS? The goal of that would be to ensure that the BTS usertag > pages are faithful summary pages for proposed orphan/remove.
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. The only garantee that we currently get is that there's no proposed removal in bapase without a bug in the BTS. But the BTS might not be tagged proposed-removal. The big problem with the workflow outlined in the wiki is the value of "eventually". After how much time is it OK to remove a package? The point of bapase was to provide reasonable values for that, and automatically track the status of all the packages. If we lose that, and let people determine themselves when it's appropriate to remove packages, it's a big step backward. I don't have any strong feelings about ditching bapase. But the new process should provide an automated way to track which packages can now be removed (because the waiting period has expired). -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
