Re: DEX ancient-patches: where the rubber meets the road

[Matt Zimmerman <mdz@debian.org>]

On Sun, Apr 03, 2011 at 11:39:23AM +0200, Stefano Zacchiroli wrote:
> [ 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. ]

I'd like to ask that all of you subscribe to the debian-derivatives mailing
list, since that's the designated list for DEX discussions.  I can't tell
who is already subscribed, but if you've signed up as a member of the team,
you should probably be on the list.  The traffic is quite low by Debian
standards, and this is where we're coordinating all of our work.

http://lists.debian.org/debian-derivatives/

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

No, I don't think this particular set of bugs has been usertagged yet.

> 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

Sounds fine to me.

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

It's true that the maintainer has most of the authority in this case, but
there's a lot of room for discussion.  If the maintainer has expressed a
desire not to merge the patch, based on general principles, we can try to
make a case for an exception.  The dhcp3 de-rooting patches have tangible
security benefits, for example.

Patches like this one make sense in Debian for the same reasons they do in
Ubuntu.  I think we should try as hard as we can to eliminate the delta by
focusing on these common interests.

Unfortunately, it's common that these discussions don't reach a clear
conclusion, and instead the bug remains open, not "wontfix" but "to fix
someday", and that's a loss for Debian and DEX.

If a maintainer takes exception to a specific patch, we can try to re-work
it to make it acceptable.  However, if the maintainer won't accept *any
patches at all*, that's a serious obstacle and we need a better answer to it.

> 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 think that at this point, we should start working on an updated package
for sysklogd.  There is some work to be done to extract the updated patch
from Ubuntu, and package it for Debian.  That work will be useful if the
maintainer responds, or for a delayed NMU, so it seems worth doing.

Would any of our volunteers be willing to help with this task?

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

I think that doing uploads is well within the scope of DEX, where this will
improve Debian and reduce the delta with a derivative.

-- 
 - mdz