On Thu, Dec 10, 2009 at 11:22:52PM +0900, Charles Plessy wrote: > As you can see, there is no option for “Request by simple > developer”. Actually, it may be a good filter to avoid that people > directly poke the FTP team without making sure that there is consensus > for the removal. This is why I like a workflow that starts by a bug on > the package.
I agree on this. In fact, my attempt at creating an "NMU-like" process
was meant to make more widespread the ability to request package
removals. Actually, I feel it is very related to NMU, because it is
exactly when you're squashing RC bugs that you might end up on
worth-removal packages. We hence need a workflow that the wannabe-NMUer
can employ to request the removal.
> Similarly, for the severity, using “Serious” from the beginning spends more
> Debian volunteer time than a non-RC severity. For instance, in the case of a
> NMU to close a RC bug, it would not make sense to open a new RC bug to
> document
> concerns on the future of the package, since the package would then stay in
> the
> radar of people dedicating time to prepare the next release.
I agree on this too. In fact, right now there are several bugs in the RC
list that are just removal requests and that I found "pollute" the
list. I believe they are there only to keep high the attention on them,
but they probably deserve a different road (as long as we can convince
the release team that the different road is actively and periodically
pursued).
> I (re?)discovered bapase in this thread, and to me it really seems that both
> tools are complementary. Bapase has basically only a couple of lines of text
> to
> store information, while the BTS can hold much more. I think that typically, a
> proposition for removal would contain a summary about the activity of the
> maintainer and upstream, as well as an inspection of the neighbour nodes in
> the
> package dependancy network. From my experience of privately inspecting
> packages
That's true, but Lucas concern about the fact that those few bapase
lines are machine parseable, whereas bug logs are not, is a valid
concern. The action item pending there is a request on how to encode
current bapase info in bug meta-data (I've on my todo list, but I
haven't yet had time to work on it, help is welcome).
> As discussed in this thread, there needs a couple of incentives to let
> people insert entries in bapase. Commit facilities, like a good Alioth
> ACL, and a checkout alias like ‘bapase-checkout’ or ‘debcheckout
> bapase’ if there would be some good reason to create a bapase binary
Actually, I believe that should be even simpler, a-la "bts" which is
fire and forget.
> In addition, a good advertisement like the improved wiki page written
> by Stefano. I actually think that once it is stabilised, it would
> really belong to the Developers Reference.
Yep, in addition to that I was thinking about preparing a sort of
announcement of the new workflow for d-d-a, because it is really
something we now need more and more to keep the archive clean. But all
this is still a bit premature. I believe the more pressing need is now
answering to Lucas' concern thinking a bit more about the synergies
between the BTS and bapase ...
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{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
signature.asc
Description: Digital signature
