Strawman: eliminating debdiffs

[Michael Bienia]

On 2008-10-01 16:04:56 +0100, James Westby wrote:
> On Wed, 2008-10-01 at 16:25 +0200, Michael Bienia wrote:
> > On 2008-10-01 10:27:49 +0100, James Westby wrote:
> > > 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.

The question is why are so few patches forwarded upstream? Is it because
the people forget it or because they find it to complex (jump through
too many hoops)? Or simply don't care?
If people find it too complex, we should see how we can make it easier
instead of forcing them to get it forwarded first. This won't make more
patches get forwarded but just less bugs fixed in Ubuntu. So it's a
lose-lose situation instead of a win-win one.

> > >   * 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.
 
I understood your proposal in that way that most of the fixes currently
sponsored should come through new upstream version and not getting
sponsored in the first place. So this barrier shouldn't be that low.

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

For typos in some descriptions, documentation, menus, etc. I agree with
you that we can wait for a new upstream version to get them fixed. But I
don't believe that's this is the greatest amount of bugs sponsored.

How do you plan to determine which bug is "important enough" to get
fixed now? Is a crash important enough? Or only if it affects a certain
number of users?
Packages in "main" get updated regularly, so one can affort it to wait
on a new upstream version for a minor fix. But there are also packages
in "universe" where the last 3 releases didn't see a new package from
Debian. Waiting here for a new upstream version or even a new Debian
revision containing a fix can be quite long. Where do you want to draw a
line?

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

That would be really good. I already try to write my own changelog
entries in a way that I still understood in 6 months (during the next
merging) why a fix was applied.

But I also find changelog entries during merging where I need to look up
the original bug report to see and understand why a patch got applied to
know if it's still needed or not. So I would prefer better changelog
entries.

But to be honest: do you really believe that sponsors will write better
changelog entries than contributors? Both are capable of writing "Apply
patch xy to fix bug/crash in foo (LP: #xxx)" into a changelog entry.

And when should contributors learn writing good changelog entries when
not while they are getting sponsored? I feel it's too late to teach them
once they're MOTU.

Regards,
Michael