What are you doing next Friday?

[Serge Hallyn]

Quoting Evan Broder (evan at ebroder.net):
> On Mon, Feb 27, 2012 at 12:05 PM, Serge Hallyn
> <serge.hallyn at canonical.com> wrote:
> > Quoting Evan Broder (evan at ebroder.net):
> >> On Mon, Feb 27, 2012 at 9:54 AM, Bryce Harrington <bryce at canonical.com> wrote:
> >> > Basically the items all need forwarded upstream and/or wrapped up in
> >> > debian packaging properly.  I'd only display them if the item includes
> >> > debdiff (or has a branch merge proposal that includes a debian/changelog
> >> > entry, if that can be detected).  Needless to say, the add_quickless
> >> > procedures should be amended to include a packaging step (for which I'm
> >> > sure you know of a suitable doc.)
> >>
> >> This is something of a separate discussion, and I don't think it
> >> applies specifically to the quicklist items since they have other
> >> issues, but I did want to address it since you brought it up.
> >>
> >> We should encourage good habits like writing changelogs and quilt
> >> patches, but we shouldn't do it at the cost of accepting the
> >> contribution at all. It's easy for a sponsor (who's obviously an
> >> experienced Ubuntu developer in their own right) to spend the 60
> >> seconds it takes to reformat the patches themselves, and it refocuses
> >> the discussion on the actual content of the change instead of the
> >> nitpicky details around our packaging processes. The only reason I can
> >> think of not to do this is if you can't come up with the necessary
> >> provenance information for the quilt header on your own.
> >>
> >> When we see bare patches in the queue, we should be willing to
> >> quilt-ify them, add a changelog, and upload, then point the
> >> contributor at the docs so they can do it themselves next time. I
> >> usually use http://developer.ubuntu.com/packaging/html/udd-patchsys.html#develop-your-patch
> >> and http://developer.ubuntu.com/packaging/html/debian-dir-overview.html#the-changelog
> >
> > I'd have no problem with this at all.  I've agonized over what to do in
> > this case myself.  I've chosen to ask the contributor whether they
> > preferred re-doing it themselves, or just wanted us to take care of the
> > patch.  I didn't want to 'cheat' them out of the experience of doing it
> > all themselves by just leaping in there and doing it.  But at the same
> > time if they *did* want to just dump the patch and move on, then I'm
> > just annoying them.
> >
> > Would it be better to just make the changes, submit them (in my case,
> > as I likely don't have upload rights, do a new merge request in place
> > of theirs), and explain to them for next time what to do?
> >
> > Even as I type this I keep going back and forth between thinking the
> > contributor would hate that or would prefer that.
> 
> My intuition (based on anecdote from non-Ubuntu-y developer friends
> and not real data) is that most people just want to dump patches on
> us. Furthermore, if they did want to do it all themselves, they're the
> sort of person likely to be a repeat contributor anyway, so at worst
> they'd only get "cheated" the first time and would have additional
> opportunities to do it all themselves later.
> 
> IME, people are pleasantly surprised when they drop a patch on LP and
> that results in a package getting fixed; I've never heard of someone
> being disappointed they didn't have to go through another round of
> review.
> 
> I think the most important thing is to give the contributor credit for
> the whole shebang (i.e. the closing line on the changelog, so they
> show up as the "changed by"), pretty much regardless of how much work
> you do on the package.

Thanks.  I'll do that in my next session.

-serge