What are you doing next Friday?

[Evan Broder]

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.

- Evan