[John Peterson <peterson@cf...>]

On Wed, Dec 12, 2012 at 9:32 AM, Kirk, Benjamin (JSC-EG311)
<benjamin.kirk-1@...> wrote:
> On Dec 12, 2012, at 9:28 AM, John Peterson <peterson@...> wrote:
>
>> The development branch can be periodically merged into stable, perhaps
>> automatically by buildbot whenever tests pass.
>>
>> So core developers would primarily work with the development branch,
>> and users who lie somewhere between "core developer" and "downloader
>> of release tarballs" would use the stable branch.
>
> I like that model, at least as a point of departure.
>
> Would there be consensus then in
>
> (1) treating 'master' as the place for stable code, along the lines of Roy's suggestion,
> (2) creating 'devel' where the core developers live.  Follow a nearly-centralized model (for now anyway as we wean from subversion), where anyone can push anything that compiles and passes 'make check' into devel.  Most libMesh CI instances would follow devel, to help spot things like compiler compatibility, PETSc backwards compatibility, etc… before syncing to master, and
> (3) again, per Roy's suggestion, any of the core developers (or buildbot) can sync devel to master whenever it is sufficiently mature and tested.

Sounds fine.


> The only additional thing I'd push for is that automatically generated files live only in master.

I don't know if this is possible in exactly the way you state it.  I'm
picturing devel as a (remote) branch off of master that periodically
gets merged back in to master.

Since the Makefile.in's already exist in master, they will also exist
in the "devel" branch which is created from it.

Hence if you modify the Makefile.in's on devel (through running
bootstrap) they'll show up as files with local modifications (not
untracked files).

You can't rebase or checkout different branches if you have local
modifications... you have to deal with them somehow.

One way is to temporarily 'git commit' the files, switch branches,
rebase, etc., and then  'git reset HEAD~1' to undo your temporary
commit.

It'll be up to you, as you mentioned, to determine when they really
have changed in a non-trivial way and need to be updated (actually
pushed to devel).

--
John