Re: where to leave info about "bad packages" (in the bapase sense)
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
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: