Strawman: eliminating debdiffs

[Justin Dugger]

On Thu, Oct 2, 2008 at 3:00 AM, Stefan Lesicnik <stefan at lsd.co.za> wrote:
> On Wed, Oct 1, 2008 at 6:20 PM, Scott Kitterman <ubuntu at kitterman.com> wrote:
>> I think your proposal would actually make the dropped fixes problem worse as
>> you've increased the amount of work needed to get a patch to the point where
>> is can be considered for sponsorship.  Many people just aren't going to do it.
>
> I agree that we need to get more changes upstream, and agree, if
> things do get fixed upstream, we have less work when it comes to
> merging in the new development cycle. I think Kees said it - that
> there is a huge effort required in learning about upstream and how
> they want things done.
>
> I also agree with ScottK about the amount of learning new contributors
> need to do. I think it is quite easy to discourage newcomers when
> difficult processes exist with no clear way of doing something.  Other
> MOTU's also may not be of so much help, because they are unfamiliar
> with a particular upstream themselves. With regards to small bugs
> about spelling / control file changes etc - I think these are great,
> because it gives new contributors a quick easy win to boost confidence
> and that feeling of, I can contribute.
>
> I quiet like the Debian adoption of packages, where you would have one
> or a group of maintainers closely integrated with upstream who can
> facilitate everything around a particular package. I guess we have LP
> teams for this...
>
>> In general the scarce resource that we need to conserve in the sponsorship
>> process is the sponsor's time.  I think this would use more rather then less
>> of it, so I don't think we should do this.  I do, however, completely agree
>> with the goal of trying to encourage more upstreaming of changes.
>
> How about the converse, is there anyway we can make upstream work more
> closely with us?  Im not sure how, but if upstream could be looking at
> our bugs, perhaps pulling in our patches, and fixing upstream, that
> would be great.  Could upstream / Ubuntu appoint some kind of liaison
> for this?  Maybe we need to find some other ideas to get upstream to
> work more with us?
>
> Stefan

I do the following for a small set of packages I use regularly:

1. Subscribe to the upstream mailing list
2. Place myself as a bug contact for the package
3. Work to triage the set of bugs reported on Launchpad
4. Report problems I can't figure out or solve myself to upstream
5. Deliver patched packages only after upstream peer review

This is closer in practice to the Developer role within Debian.  The
downside is that this isn't practical for large sets of packages, like
say "universe".  And it does rely on people assigning bugs to the
right package at some point.

The trouble I find is that sometimes upstream is unreponsive or even
hostile to Ubuntu. And every upstream is unique.  For example, I've
discovered the linuxwacom project leader prefers that I not forward
bugs in their tracker, instead wanting the bug reporter to repeat
themselves on the mailing list. Linuxwacom supports a lot of devices,
more than I own, so it's hard for me to duplicate a bug to have
productive upstream conversation.

Each upstream has unique quirks like that; and as Stefan says, MOTU
have such a wide array of packages that they can't afford to spend
time understanding upstream. I think part of the solution involves
getting people to contribute to Ubuntu in more focused chunks similar
to the way I have.  The rest of the solution lies in promoting best
practices, both through Launchpad and through conversation and
conferences. Things like using revision control, patch review, bug
tracking and release engineering.  Making it available isn't enough;
you also need to demonstrate it's utility and establish a culture of
using the tools effectively.

It won't solve the problem over night, but it at least gives everyone
a fighting chance.

Justin Dugger