On Tuesday 06 December 2016, Karel Zak wrote: > On Mon, Dec 05, 2016 at 01:27:11PM -0500, J William Piggott wrote: > > On 12/05/2016 06:51 AM, Karel Zak wrote: > > > On Mon, Dec 05, 2016 at 11:25:45AM +0100, Michael Kerrisk (man-pages) wrote: > > >> I have various fixes to send, but I'll start small, with a > > >> couple of fixes for nsenter(1). > > > > > > Applied ... but you have removed "See also.. " sentence from > > > description of the --user. Would be better to keep there? > > > > > >> Is a git pull request compatible with your > > >> workflow? > > > > > > Sure. > > > > Does this apply to all of us? We no longer need to submit patches > > to the mailing list for peer review? > > Well, send patch to the mailing list for review is always good > choice, and it's definitely wanted for invasive or sensitive things, > or if you're not sure. > > I think for trivial changes where is nothing to discuss it's probably > good enough to send pull request only. > > It's also good idea to keep the latest version of your patches in > public remote repository (e.g. github) if you expect any additional > changes after review etc. > > > Use common sense anyway. It works better than strict rules. One thing I would really like is that you would merge the mailing list patch-sets in the same way like github does, using "git merge --no-ff". This always adds an explicit merge commit which makes IMO later review and bisecting easier. (Less uninteresting/intermediate points in master.) Though maybe other people would rather like a simple straight forward master branch. Anyways this is just my vote for --no-ff :) cu, Rudi -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
