Busy work

Clint Byrum clint at ubuntu.com
Fri Feb 4 19:00:03 UTC 2011

On Fri, 2011-02-04 at 10:22 -0800, Akkana Peck wrote:
> Reuben Thomas writes:
> > In the last two and a half years, it has twice received the attentions
> > of Ubuntu developers. Once, two months after I filed it; once, just
> > now. Each time the developer changed some tags.
> [ ... ]
> > it's 30s of editing. Arguably, my bad for not providing
> > a patch; but again, I thought that would be a waste of time, because
> > it would take longer for me to produce a patch, be sure that it was
> > clean, and applied to the latest version of the package, and then for
> > the developer to apply it, than for the developer simply to edit the
> > man page themselves and produce a package patch.
> Including a patch often doesn't help anyway. That just leads to "can
> you make a debdiff rather than a patch?" Make a debdiff, and it turns
> out you should have made a PPA.  Make a PPA, and there are further steps.

Ultimately, the sponsorship and patch review process was broken for a
while because of the cadence required of Ubuntu developers to

Before, they were asked to spend 1 hour per week sponsoring. This
allowed only shallow review, so a user would see exactly that.. a 5
minute "oh that patch looks ok, but can you put it in a debdiff?" Then
the next sponsor would see the debdiff and try it and say "it failed
here, can you fix problem X and the upload it to a PPA for building?".

With the recent change to a patch pilot, you should see a more in-depth
review. The developer is working for 4 hours straight on sponsoring
patches. So while the spectrum of sponsorship won't be very wide, you
should see that a developer has the time to look closely at the patch,
and possibly even put it into a debdiff and fix the bug.

So I'd say, give patch pilot a chance before damning the old process.

> After a while you realize it's a lot less work to maintain your
> own copy of the package source locally than to keep trying to find
> the magic steps to get the fix into Ubuntu.

Its easy to fix a problem for yourself because you have the source, and
you have your use case. Its not always easy to fix it in a generic way
that will work for most use cases.

> (For instance, bugs 553415, which did finally get checked in after
> a lot of work on many people's parts, and 370735, which is still
> crashing on startup a year and a half after a patch was posted ...
> and yes, I should probably learn how to make a debdiff, but
> I got discouraged seeing how that didn't help in other bugs.)
> It would help a lot to have a guide -- one that's easy to find,
> maybe linked from launchpad bug pages so bug reporters can find it --
> with a clear explanation of the steps needed. Then have developers
> actually accept patches that follow those steps.

This does a fairly good job, maybe we need to make it easier to find?


> Same with the SRU process: https://wiki.ubuntu.com/StableReleaseUpdates
> is confusing because steps 1-3 can be done by anyone, then you hit step
> 4 and ... wait, upload how? is this guide meant only for developers?

>From the linked page, step 4:

..."If you can't upload to the archive yourself, get a sponsor, attach a
debdiff to the bug and subscribe ubuntu-sponsors, as usual. There is no
need to wait before uploading."

"get a sponsor" links to..


> Also, step 3 says to make a patch, but in at least in bug 553415
> it was necessary to make a PPA and get people testing the patch.
> That's perfectly reasonable -- but it would be great if the guide
> explained the real steps a bug reporter should go through.

SRU's need to be tested widely. Sometimes the simple verification step
isn't enough, the sponsor wants things to be even easier to test. In the
case above, the fix had a large potential for regression, so it may have
harmed testers using the -proposed archive, hence the need for a PPA.

More information about the Ubuntu-devel-discuss mailing list