Busy work

Chris Sherlock ta.bu.shi.da.yu at gmail.com
Mon Feb 7 12:27:37 UTC 2011

> On Fri, 2011-02-04 at 18:46 +0000, Chris Coulson wrote:
> > On Fri, 2011-02-04 at 10:22 -0800, Akkana Peck wrote:
> >
> > > > 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.
> >
> >
> > I don't really consider a debdiff to be a necessary requirement for
> > sponsoring a bug, especially if it is just dropping in a patch touching
> > upstream code. What matters is that the patch is correct and of the
> > required quality. It's not difficult for sponsors to create a package
> > using a patch that a contributor has attached to a bug report (after
> > all, the extra work is normally just creating a changelog entry, which
> > isn't particularly hard).
> >
> > I hope your experience isn't the norm. If we are driving away
> > contributors and turning away good patches because somebody hasn't
> > provided a debdiff, then this makes me both sad and angry.
> Chris, Seems you are among the few odd-ones-out among the sponsors! (/me
> takes note for future ;p)
> What Akkana mentions is what happens even today.
> If there is no debdiff, sponsors just comment: "bug report has no
> debdiff to sponsor here, unsubscribing sponsors. Pls resubscribe when
> there is a debdiff".  (similar for the merges with no changelog entries)
> Some sponsors even get angry when subscribed for a patch. ;-)
> Some sponsors subscribe the Review team to make the patch -> debdiff,
> and ask to be resubscribed later.
> But review team effort is not sufficient. One problem often faced is,
> after the patch->diff work is done, it is not sufficient enough for the
> patch to be uploaded, Because the patch needs to be sent upstream for
> their review and sponsors again unsubscribe from the bug. (yes, the
> reviewer should know these should go upstream! but it is more of a bug
> in our tools/workflow)
> The problem is, we are allowing patches to be attached for such
> packages. We have the bugs open in lp and since Ubuntu is the distro
> they use, they attach the patch on lp and wonder why we wait and dont
> just upload.
> Very few new folks realize that Ubuntu is more of package work than
> actual app/package development.
> IMO, Kubuntu folks have a better workflow. If it is not a bug caused by
> Ubuntu changes, they just close the lp bug and continue discussion on
> the upstream bugs. Which makes it a bit clearer where the
> patch/discussion needs to go.
> I'm not suggesting that we suddenly switch our entire workflow, but
> Maybe not allow patches to be uploaded for packages not hosted on lp or
> notify when patch is being attached and only allow to attach when they
> choose to ignore the notification?
> Not sure what the ideal solution is but whatever it is, we need to make
> sure that we dont accumulate patches in lp and drive away potential
> contributors.
> --
> Cheers,
> Vish

I'm quite new to this whole process, but if patches are frowned on in
lp, then why are these accepted?!?


More information about the Ubuntu-devel-discuss mailing list