Strawman: eliminating debdiffs

[James Westby]

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

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.

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.

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.

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!

Thanks,

James