[MOAB-dev] MOAB git branching model

[Vijay S. Mahadevan]

> I'm reluctant at the moment to institutionalize this, though for large
> changes or design changes I agree that it's helpful.

I am all for this and have wanted to make this the default model for
feature additions since we moved to bitbucket. This allows better peer
reviewed code, testing with different configuration options and keeps
master stable.

I like the PETSc model too (master+next) but considering there are few
active developers pushing fixes/features for MOAB, it might still be
early to move in that direction. My 2 cents.

Vijay

On Thu, Sep 19, 2013 at 11:40 AM, Tim Tautges <tautges at mcs.anl.gov> wrote:
> 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
>