Strawman: eliminating debdiffs

[Matt Zimmerman]

On Thu, Oct 09, 2008 at 01:59:25PM +0100, Colin Watson wrote:
> This is perhaps going off on a slight tangent, and anyone who knows me
> will probably have heard versions of this rant before, but I have
> noticed roughly the following dysfunctions with the current process:
> 
>   * People are encouraged to prepare debdiffs for trivial changes
>     (description adjustments, typos, etc.). This encourages
>     trivial-change uploads when they aren't really necessary, rather
>     than batching up a number of changes at once, and it reinforces the
>     bogus idea that the form of a debdiff is important even when the
>     change is manifestly trivial ("hey guys, could you change "foo" to
>     "bar" please?), thus wasting everyone's time.
> 
>   * Many sponsors go back and forth with the contributor quite a lot
>     over trivial adjustments, such as changelog style. This is done with
>     noble intentions, namely training up contributors, but the end
>     result is often to put contributors off because they have to jump
>     through hoops that aren't really all that important. Furthermore,
>     this produces a skewed idea among contributors about what really is
>     important. We should be punting things back to the contributor when
>     the changes required are substantive, and just making minor
>     adjustments ourselves for trivial things and informing the
>     contributor about what we did. This is what I do myself.
> 
>   * Asking people to produce a fully-formed debdiff, including
>     changelog, that can be applied and uploaded directly is often a net
>     loss: if the package is maintained in revision control and there are
>     already changes outstanding then you have to merge the changelog,
>     which is usually no easier than just writing the dratted changelog
>     entry yourself. Most upstream projects are far more sensible than
>     this: if you supply a proposed changelog entry in the mail or bug
>     report along with the patch then they'll include that, and otherwise
>     they'll just write one. After all the upstream maintainer has to
>     understand the patch in order to merge it anyway!

Agreed, though I think these three points should be largely addressed by
allowing contributors to create branches rather than diffs.

>   * Sometimes people send a perfectly good patch in an Ubuntu bug report
>     and then somebody says "in order to get this included you should
>     attach a debdiff instead". This is *a complete and utter waste of
>     time*. A debdiff is just a kind of patch and any Ubuntu developer
>     who can't figure out how to apply some slightly
>     differently-formatted patch in a matter of seconds shouldn't be an
>     Ubuntu developer. What bug triage processes recommend that people
>     say this and how can we get them fixed? I know people who are
>     perfectly competent developers who think we're mired in useless
>     bureaucracy due to this and have been put off contributing.

Completely agreed on all points.  I have seen this before as well, and think
that the drive to convert patches into debdiffs has been misguided.

>   * As you say, there is little incentive for anyone to submit patches
>     upstream because that's not the main thing they're measured on when
>     attempting to join the Ubuntu development team.

Productive engagement with upstream should count for a lot when considering
people to join the development team.  If they aren't, that's a bug.

> Scott Kitterman writes [2] that he feels that this will be more
> intimidating for new contributors. While I can see his point, our
> process is actually considerably more complicated than the process of
> contributing to most upstream projects (once you invest a little capital
> in figuring out how to do so; I acknowledge Kees Cook's point that this
> is sometimes difficult but I don't think that's the case for the vast
> majority of packages in Ubuntu).
>
> Mostly, you mail somebody a patch or stick it in a bug tracking system
> somewhere, and either they say "thanks, applied"; or you have a bit of
> an argument about whether it's the right thing or suggestions for
> improvements; or maybe they reject it and say they aren't interested; or
> you get ignored. Not all of these possibilities are good outcomes but at
> least they're relatively simple. In Ubuntu right now you get bounced
> back and forward among different teams, you have to supply your patch in
> an extremely specific format, you might have to get freeze clearance,
> all sorts of stuff that essentially amounts to safeguards against us
> doing the wrong thing.

This is an interesting point, but I think the lesson here is that our
process needs work, rather than that contributors should be redirected
upstream.  It fundamentally *should* be simpler in Ubuntu because we can
have a single, standard process for all packages.

> If the patch is not fundamentally Ubuntu-specific in some way, I think
> contributors will actually often be better served by sending patches
> upstream first, and then documenting that they've done so in the
> corresponding Ubuntu bug report and perhaps going through whatever
> rigmarole is needed to get the patch applied in Ubuntu. For anything
> non-trivial related to a package where we don't have significant
> expertise in Ubuntu, upstream is the place where your patch is going to
> get serious review and commentary. It's usually so much more pleasant to
> work with developers who know the code you're working on really well.

This is an excellent point, and any patches we add to Ubuntu should
absolutely go through an upstream review process.  I just don't think this
can be the primary means for patches to be contributed.  If someone is
looking to Ubuntu to contribute their patch, it's either because it affects
Ubuntu users particularly, because they're part of our community and want to
help out, because it's more expedient for them, etc.  Redirecting these
efforts upstream can adversely affect the motivation of the contributor.

A patch which arrives upstream saying "I'm testing this out in the Ubuntu
package, what do you thisk?" or "We've tested this for a while and it seems
to work, how about merging it?" seems more valuable as one which says "works
for me".

In short, I agree that submitting upstream is an essential part of the
process, but I think it should happen more in parallel rather than serially.

-- 
 - mdz