Strawman: eliminating debdiffs

[James Westby]

On Wed, 2008-10-01 at 16:25 +0200, Michael Bienia wrote:
> 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).

How does this differ from the current state? This would imply
either forwarding other people's patches, or not forwarding
the patches at all, both of which I think are bad ideas.

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

That is a fair point.

I guess an alternative would be forwarding when merging, but there
will we be some projects where we are always behind, and I don't like
the idea much anyway.

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

"...if the contributor deems the fix important enough to warrant an
upload before the new upstream is packaged they seek a sponsor."

I don't see how this means that users have to wait twelve months for
fixes. We could set "important enough" so low that everything qualifies,
and that would mean that this proposal is not that different from the
previous one about putting the links in the changelog.

However, I said "important enough" as I don't think everything should
qualify.

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

I propose lower down that for non-trivial things someone prepares the
debdiff before a sponsor gets to it, and I agree that putting too
much work on the sponsors would be a bad thing.

The point of having the sponsor write the changelog entry is that
it shows the problem and the fix are well documented enough for
other people to understand, and the sponsor can write it as someone
not involved in fixing it, and so they will hopefully recognise the
important bits of information. It would hopefully mean that things
would be much more clear for the next merger.

One other small benefit is that you don't have patches failing
to apply due to the changelog if a new version was uploaded to
the archive in the mean time.

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

How do you propose we handle this for the current situation? We end
up with a patch that upstream doesn't like, and we have to sort this
out later. Possibly having to deal with backwards compatibility 
headaches if upstream goes a different way.

At least under my proposal you would have a chance of knowing this
before upload, so you can reconsider.

I think the review from upstream is an important consequence of
the proposal. It will hopefully stop this divergence from happening,
as I believe we should try our hardest to get things pushed upstream,
and knowing about upstream's concerns before committing to an
approach must surely help.

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

Launchpad can track bugs in multiple bug trackers, so when you open the
upstream bug you link it to the Ubuntu one, and then you can look at the
report of bugs fixed elsewhere and check that we have pulled them in.

Thanks,

James