Busy work

Akkana Peck akkana at shallowsky.com
Fri Feb 4 18:22:05 UTC 2011

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.

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.

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

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


More information about the Ubuntu-devel-discuss mailing list