On Mon, Dec 07, 2009 at 08:55:58AM +0100, Lucas Nussbaum wrote:
> 50 days might be too much, but 10 days (in the general case) is
> definitely too short. I agree that there might be cases where waiting 10
> days is appropriate. But using 10 days by default will allow for many
> packages to be removed by mistake. I would prefer if it was recommended
> to choose a delay between 10 and 30 days, with 30 days being the
> default.
Fair enough, I'm fine with that.
> > 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?
>
> No, please don't! We really want to review the bugs again before asking
> for removal. Many people have been unhappy with the ITA/ITP retitler
> because it was changing the state of bugs they were actively working on.
> Here, we are talking about decisions that are much more important.
> [ or, we could start by not doing automated reassignings, and revisit
> this in 6 months if we really think that it's stupid to do it manually ]
Let me explain my problem without the automatic reassign. What I'm
worried about is the increase in the number of steps required to
*propose* a removal: each step you add that miss a clear benefit, adds
inertia to the system and risk "forgetting" about the removal need.
It seems to me that your view is something like: we follow the package
for a while and, before the final crucial reassign step, we thoroughly
check if the package is really worth removing; if it is, we reassign.
My view is rather something like: we thoroughly check whether a package
is worth removing *before* tagging the package proposed-removal and once
that is done we just leave the (probably MIA) maintainer the time to
react. At that point, the only action that can "save" the package is the
maintainer complaining. If he does not react the package will be
automatically turned in a RoQA removal request.
Now that I've written that, I do agree that the current tag name
"proposed-removal" is more coherent with your view than mine. The
problem with yours is that it has a lot of inertia/centrality: it is not
enough for maintainers to signal the need of removing a package and then
just wait; someone else (a team or something such) needs to periodically
re-check again, do something, and finally ftp.d.o check everything
again. It might be good of course, because we end up being more
careful, but how can we ensure we actually *do* the central QA review
step periodically?
> But I understand that some people don't want to invest time in bapase,
> and prefer just to file bugs. So I propose to improve bapase with a way
> to list packages with proposed-removal bugs, that are not currently
> tracked in bapase. That way, bapase-interested people could add
> information to bapase about those packages.
> Basically, this boils down to: "you don't want to care about bapase?
> Just file the bugs and usertag them, someone might add them to bapase
> for you".
OK, that sounds reasonable. In fact, it would keep bapase at it is now,
and additionally enable maintainers which knows nothing about bapase to
have a BTS-based interface to communicate with bapase. I like the
concept.
> If you really want to push for that, a good start would be to propose a
> fixed format that stores what is currently relevant in bapase. It would
> have to be stored directly using usertags, or in the bug title (UDD and
> other tools don't store the full bug log, so using pseudo-headers
> in bug messages would not work).
> See http://svn.debian.org/wsvn/collab-qa/bapase/README for the
> description of the various tags, and
> http://svn.debian.org/wsvn/collab-qa/bapase/package-actions.txt for the
> list of (package, action).
OK, will do in a separate mail.
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