On Tue, 11 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote: > http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow
Who volunteers to be integration manager? If it's not the most prolific developer then they're not going to be able to keep up (I'm recalling the FIN-S branches/kitchen-sink situation here); but the identity of "the most prolific developer" has probably swapped between three or four different people back and forth a dozen times over the years. I was picturing something not too far off from the centralized development model, but with one added step: the distinction between a Testing and Master branch. Developers can commit any change sets between Master and their private branch that pass a --enable-everything "make check" to Testing. Any newer-than-Master version of Testing that passes the continuous integration tests can (and should) be synched by any developer (or by buildbot itself eventually) to Master. Any newer-than-Master version of Testing that fails the continuous integration tests can be either: A) given another patch designed specifically to fix the failed tests, B) reverted to any other newer-than-Master revision that hasn't been tested (in cases where multiple patches were added too fast for buildbot to test) C) reverted completely by a developer who can't fix someone else's breakage but wants to then test his own new patch. Thoughts? --- Roy ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
