[MOAB-dev] MOAB git branching model

[Tim Tautges]

I'm reluctant at the moment to institutionalize this, though for large changes or design changes I agree that it's 
helpful.  The reviews by Iulian and Danqing recently were very helpful for the big merge I just did.

-- tim

On 09/17/2013 09:19 PM, Paul Wilson wrote:
>
> On 09/17/2013 05:28 PM, Tim Tautges wrote:
>> Hi all,
>>   The recent instability of the master branch of the MOAB repository (due entirely to me pushing large gobs of code)
>> has gotten me thinking about our current repository branching model, or really lack thereof.  I think it's probably
>> time to get a bit more formalized about this, in spite of my distaste for explicit processes in general.
>>
>> To review, in our current repo, we have a master branch, and several branches for previous releases.  In general,
>> other MOAB developers have been using either direct clones (w/o named branches) or forks and pull requests.  The
>> advantage of this is simplicity, but the disadvantage is having a master branch that could be unstable.
>>
>> There are two things I'd like to propose or at least start a discussion on in this email:
>>
>> 1) For developers on the project, I think we should always do that development in branches, either feature branches or
>> hotfix branches.  That will make it easier to figure out what's going on at any point in time, and for associating
>> individual merges with specific development features or fixes.  External developers (those w/o credentials to push
>> directly into MOAB master) would continue to submit pull requests as before.
> I'm not a particularly active developer at the moment, but I would suggest that all developers - internal and external -
> merge changes with a pull request process.  There are at least 2 benefits:
>
>   * pre-commit code review by another developer
>   * a more distributed knowledge of the code base as a result
>
> There is at least one real disadvantage:
>
>   * delay in merging changes because potential reviewers are too busy
>
> In the projects I work on, it has been very successful.
>
> Note - this doesn't meant that those developers need to work in a fork (although there is no practical difference).
> They can work in a branch of the main repo and issue a pull request from the branch to the main line (whatever it is
> called following item 2 and Jed's response).
>
> Paul
>
>>
>> 2) I think we should go to a more formalized repo structure and branching/release process, similar to what is
>> described in http://nvie.com/posts/a-successful-git-branching-model/.  Mostly what this would mean is that the master
>> branch would be come our "stable" or last-released version, while a development branch would be the one receiving
>> day-to-day changes (and receiving the most autotesting).  This wouldn't prevent the kind of instability on that branch
>> that I caused recently, but at least would protect non-developers from these problems.
>>
>> Comments?
>>
>> - tim
>>
>
> --
> -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
> Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal:http://bit.ly/pphw-cal
> Professor, Engineering Physics. ~http://cnerg.engr.wisc.edu
> Faculty Director, Advanced Computing Infrastructure
>

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
  phone (gvoice): (608) 354-1459      1500 Engineering Dr.
             fax: (608) 263-4499      Madison, WI 53706