Busy work

[Vishnoo]

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