Busy work

[Clint Byrum]

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

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?

https://wiki.ubuntu.com/SponsorshipProcess


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

https://wiki.ubuntu.com/SponsorshipProcess



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