Strawman: eliminating debdiffs

[Michael Bienia]

On 2008-10-01 10:27:49 +0100, James Westby wrote:
Hi,

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

That might be true, but I guess it also depends on the project where one
forwards the patch. Many projects have their own bug tracking systems
where I need a account first before I can file a bug/submit a patch. I
will end with many accounts that I only needed once (and I'm a bit
reluctant to create an account just for one use).

Does somebody know how upstream reacts about patches which aren't
against the latest version (or VCS HEAD)?

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

This new upstream version (and also the fix) might end not in the
current+1 release but in current+2 or later, depending when upstream
releases the next version, when Debian packages it and when we are able
to pull it in.

I guess our users won't be happy to wait for a known fix 12 months or
longer because we don't manage to get the new upstream version packaged.

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

I'd prefer if the sponsoree does the work: fetch the patch, make it
apply to the current version (e.g. because it comes from the VCS),
"package" it (e.g convert to dpatch or quilt) and write the changelog
entry. I don't guess that sponsors have that much time to do it on their
own.

What do you propose for patches that upstream doesn't like (e.g.
upstream doesn't like the proposed solution (e.g. prefers a rewrite) or
the patch is too specific on Ubuntu, etc.) but is still needed for
Ubuntu?

An other issue is how do you plan to track which bugs got closed by new
upstream version? I'm pretty sure that there are bugs in LP which can be
closed because a new version fixed it but are still open because nobody
noticed.

Michael