[ Preserving Cc:-s as requested by Matt's Mail-Followup-To, let us know
if you don't want to be Cc:-ed in the future, folks. ]
On Wed, Mar 30, 2011 at 02:42:11PM +0100, Matt Zimmerman wrote:
> http://dex.alioth.debian.org/ubuntu/ancient-patches/status/
>
> At this point, all of the straightforward work is done. Obsolete and
> merged patches have been filtered out, and those which remain have
> open bugs in the BTS.
That's very cool indeed!
I've a question about the status page, more because they are likely to
be reused as prototypes for future status pages than to change the
specific status page about ancient-patches. As it is, the status page is
very cool and the cake diagram very telling. However I can't find a link
to a bugs.d.o report page which uses usertags to gather together bugs
related to the ancient-patches project.
Have those bugs being user tagged in addition to collected on the status
page? While it might seem duplicate work to do so as well, usertagging
would allow to query the status of bugs pertaining to a specific project
using either the SOAP interface or UDD. The latter would be particularly
useful for QA initiatives, which might want to use DEX gathered data to
spot, for instance, unmaintained packages.
If the usertagging hasn't been done yet, I hereby propose the following
scheme for usertags in DEX projects:
- user: debian-derivatives@lists.debian.org
- usertag: dex-SUBPROJ-SUBPROJNAME
The usertag is a scheme. For ancient-patches it would map to
dex-ubuntu-ancient-patches.
If we decide to go ahead with the usertagging, a simply script for
actually doing the usertagging would be as follow:
for bug in $BUGLIST ; do
bts user debian-derivatives@lists.debian.org , usertag $bug + dex-ubuntu-ancent-patches
done
> The end result is that these four outstanding issues are currently
> stalled.
>
> This is exactly the problem that DEX was created to understand and
> solve. These last four items will teach us the most about how to
> improve teamwork with derivatives.
There are various cases to distinguish here, imho. When the maintainer
has explicitly ack-ed the existence on the patch and argued against
including it, there is little we can do. That is a consequence of the
maintenance model in Debian, where an (active) maintainer is in charge
of their own decision on a package. If we believe hardly enough that a
patch should go in, the only potential remaining step is to raise a
conflict with the tech-ctte, but I hope we'll never have to reach that
point, essentially because we'll accept maintainer decision. Still, I
believe that in all cases where a maintainer refuses a patch, we should
reach the point where an open bug containing the patch exists and has
been tagged as wontfix by the maintainer. That way we'll have
documentation that DEX has done all that could have been possibly done
to have the patch accepted.
The other case is that of unresponsive maintainer or, equivalently, or
maintainer who respond to ping but ultimately does not ack. The
procedural devices to fix that exists, they are called DELAYED NMUs [1]
and are exactly what Jeremiah has asked for. Using appropriate delays,
one can NMU packages to fix essentially all kinds of bugs, provided the
legitimate maintainer is put in the best conditions to catch up with the
NMU later (e.g. by ensuring a bug report is filed in the BTS and that
the nmudiff is sent to that bug report). Essentially, the idea is that
one sends a last ping to a maintainer and that, at the same time, they
go ahead with a very long DELAYED NMU, clarifying that has been done in
the hope to relieve the maintainer of some duty and being willing to
reschedule it, if the maintainer asks so. I've been campaigning a lot
for the usage of DELAYED NMUs to fight maintainer inertia in Debian; DEX
is just providing other use cases for that.
I duly notice that the fact that we have a procedural device to handle
those cases does not imply that, within DEX, we have the manpower to
actually go ahead and do the NMUs. Initially we essentially decided to
do just coordination work, while NMUs do need active packaging power to
proceed.
Cheers.
[1] http://www.debian.org/doc/developers-reference/pkgs.html#nmu-guidelines
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Attachment:
signature.asc
Description: Digital signature