Quoting Evan Broder ([email protected]): > On Mon, Feb 27, 2012 at 12:05 PM, Serge Hallyn > <[email protected]> wrote: > > Quoting Evan Broder ([email protected]): > >> On Mon, Feb 27, 2012 at 9:54 AM, Bryce Harrington <[email protected]> > >> 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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
