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
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