[MOAB-dev] MOAB git branching model

[Paul Wilson]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20130917/68e1524b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20130917/68e1524b/attachment.bin>