William Allen Simpson [william.allen.simp...@gmail.com] wrote: > On 4/24/15 5:59 PM, Frank Filz wrote: > > 2a. One solution here is use an e-mail review system (like the kernel > > process). This could be e-mail exclusively (I would then have to set up > > e-mail on my Linux VM in order to be able to merge patches via e-mail). I'm > > not fond of this process, but it would be workable. > > > Of course, this is the original design rationale for git -- email review. > That's what it does best. This would be my preference.
I would prefer this as well. emails are archived at many places these days (review history is well kept), new people need not register on github or gerrit. It makes the maintainer job a bit hard. Bruce or others who have direct experience can tell us. I used to 'tag' a bunch of emails and used to apply 'git am' on them for reviewing (using mutt). Maybe, have a "staged" branch and merge commits as soon as they are done. People can see if their commits are already on "staged" branch. They bug you if they are not. Only commits from "staged" branch go into real branch on Friday/Thursday. Commits that fail your regression will not make into real branch and will be reported on the mailing list. Regards, Malahal. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
