On Wed, 12 Dec 2012, Kirk, Benjamin (JSC-EG311) wrote: > (1) treating 'master' as the place for stable code, along the lines of Roy's > suggestion, > (2) creating 'devel' where the core developers live.
My concern here is that then the core developers don't get the main benefit of the "devel"->"master" split. If you're updating your personal branch (or your personal checkout, to start) from devel, then you're going to get every insufficiently-tested patch from everyone else. Whereas if you pull from master and push to devel, you can be more certain that any breakage in your own sandbox isn't someone else's fault. The only trouble with pulling from master and pushing to devel is the "two people committed to devel before either single patch could be tested and pushed to master, and it broke" case, which is what I was trying to sort out with my convoluted alphabetized list earlier. > The only additional thing I'd push for is that automatically > generated files live only in master. Any core developer working on > devel should be sufficiently proficient to make sure they have the > autotools and can bootstrap. In this way there is no need to > everyone to have identical autotools versions when working on devel, > or living with the dreaded > > -# Makefile.in generated by automake 1.12.4 from Makefile.am. > +# Makefile.in generated by automake 1.12.5 from Makefile.am. > > noise. This I'm going to need to think about. --- 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
