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