[Strawman] Sponsoring after Permissions Reorg

[Martin Pitt]

Emmet Hikory [2009-12-09 19:13 +0900]:
>     I don't think that there is an identify between the list of bugs
> with patches attached and the list of bugs that need to be sponsored.

Full ack.

> Many patches need testing, or have not been integrated into the
> packaging.

... or not be reported upstream.

Many developers are rightfully hesitant to sponsor code changes to
packages which aren't forwarded upstream, since it puts the effort and
responsibilities from the patch author to the sponsor. First this
doesn't scale, and second the original author is in a better position
to follow up to upstream's requests about changing the patch than the
sponsor.

(At least I don't easily sponsor unforwarded code patches)

> It's easy for us to forget, but there's often a significant learning
> effort to go from being able to produce a code patch (which skill
> one may have aquired in any of a large variety of contexts) to the
> ability to prepare a candidate revision of a package for upload:
> essentially one needs to be able to understand how the packaging is
> done, which of the many available patch systems is used, how to
> properly manipulate that patch system, how to ensure that the patch
> is applied using the selected patch system in the package, etc.

This is another case why it is often better to work through upstream
directly. To be honest, as a sponsor it is much more important to me
to not have to maintain that patch long-term than to have a readily
applicable debdiff. If there's just a patch attached which is
forwarded (or even applied) upstream, it's easy for us to figure out
how to apply it into a package.

If the contributor is aspiring to become an Ubuntu developer, it's a
different issue, of course. But my own experiences in sponsoring show
that a great number of contributors don't.

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)