Strawman: eliminating debdiffs

[Scott Kitterman]

On Wednesday 01 October 2008 05:27:49 James Westby wrote:
> ...well, not eliminating, but a strawman should be provocative.
>
> Hi all,
>
> It's my opinion that our current process encourages our interaction
> with upstream projects on pushing bug fixes to be to the wrong way
> round.

As others have commented I think this depends on the bugfix and where we are in 
the development cycle.  Early in the cycle I'm more apt to push people to get 
the bug fixed in Debian/some other upstream and the sync the fix into Ubuntu.  

> Currently the typical route is for a contributor to come up with a
> fix and seek sponsorship for a debdiff. Often they won't forward
> the patch first, and the sponsor will encourage them to do this.
> Either the sponsor blocks on doing that, which gives more delays
> and can lead to dropped fixes, or the sponsor encourages the contributor
> to do it in their comment when uploading, which can be easily ignored.

I think your proposal would actually make the dropped fixes problem worse as 
you've increased the amount of work needed to get a patch to the point where 
is can be considered for sponsorship.  Many people just aren't going to do it.

> My proposal would be to discourage debdiffs for this sort of fix.
> Instead I propose the following:
>
>   * The contributor finds a fix to a problem, and forwards the
>     patch upstream. They follow the progress of the bug and
>     work with upstream to get it committed.
>   * For small fixes the process will stop there.
>   * Once the fix is committed, or some time has passed with no
>     comment from upstream, if the contributor deems the fix
>     important enough to warrant an upload before the new upstream
>     is packaged they seek a sponsor.
>   * A sponsorship request is a description of the problem and the
>     fix and a pointer to the bug report and/or commit upstream.
>   * The sponsor grabs the patch and reviews it, with more scrutiny
>     if there has been no comment upstream. They drop it in the
>     package and add a changelog entry, which will be easy because
>     contributors will be encouraged to provide a lot of information
>     about the fix.
>
> There are a couple of obvious benefits to this. Firstly everything
> is forwarded upstream, without sponsors having to push for it. This
> should help bring more experienced review from upstream of the changes
> we pull in. Also, it's easier to reject patches for unimportant things
> from the sponsorship queue, as the contributor knows that it will be
> pulled in eventually.

We don't need a policy change for sponsors to tell people "This is a trivial 
change and it's not worth the effort of maintaining the diff in Ubuntu to have 
it.  Go get it fixed in Debian/wherever."  I've pulled stuff out of the 
sponsorship queue and done this in the past and it's gone fine.  

I guess I don't understand 'easier to reject'.  Rejecting now is trivially 
simple: write a comment in the bug and unsubscribe UUS.

Also consider how this new process would appear to new contributors.  The 
current process is very intimidating for new people already.  If we mandated 
this approach, then things would be substantially more overwhelming for 
newcomers.

I think we'd have less divergence from Debian/upstream, but many fewer fixes 
and fewer new contributors.

> One issue is that the contributor won't necessarily get record of their
> work on their /+packages page. The sponsor could use their details in
> the changelog footer, but some sponsors may not like that as they did
> the work of pulling the fix in to the package.
>
> There are also cases where pulling the fix in isn't easy, in those
> cases a debdiff could be requested to save overloading sponsors.
>
> Contributors who are keen to become developers could help triage the
> queue. They could review the submissions, and for any they think
> are worth an upload they could prepare a debdiff, hence learning
> the mechanics of packaging.

People can do this now.  I think that adding something with a simple patch to 
the sponsorship queue is just fine and if someone wants to rework that into a 
debdiff to save the sponsor time, that's great.

> There are obviously changes for which there is no upstream, or where
> it's not appropriate to forward them, and these could be handled in
> the current fashion, but the default could be to encourage changes
> in the way described above.
>
> Fire up your torches!

No torch, because I appreciate the attempt to think out of the box and make 
things better.

In general the scarce resource that we need to conserve in the sponsorship 
process is the sponsor's time.  I think this would use more rather then less 
of it, so I don't think we should do this.  I do, however, completely agree 
with the goal of trying to encourage more upstreaming of changes.

Scott K