<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 09/17/2013 05:28 PM, Tim Tautges
wrote:<br>
</div>
<blockquote cite="mid:5238D78B.20507@mcs.anl.gov" type="cite">Hi
all,
<br>
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.
<br>
<br>
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.
<br>
<br>
There are two things I'd like to propose or at least start a
discussion on in this email:
<br>
<br>
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.
<br>
</blockquote>
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:<br>
<ul>
<li>pre-commit code review by another developer</li>
<li>a more distributed knowledge of the code base as a result</li>
</ul>
<p>There is at least one real disadvantage:<br>
</p>
<ul>
<li>delay in merging changes because potential reviewers are too
busy</li>
</ul>
<p>In the projects I work on, it has been very successful.<br>
</p>
<p>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).<br>
</p>
<p>Paul<br>
</p>
<blockquote cite="mid:5238D78B.20507@mcs.anl.gov" type="cite">
<br>
2) I think we should go to a more formalized repo structure and
branching/release process, similar to what is described in
<a class="moz-txt-link-freetext" href="http://nvie.com/posts/a-successful-git-branching-model/">http://nvie.com/posts/a-successful-git-branching-model/</a>. 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.
<br>
<br>
Comments?
<br>
<br>
- tim
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ --
Paul Wilson ~ UW-Madison ~ 608-263-0807 ~ cal: <a class="moz-txt-link-freetext" href="http://bit.ly/pphw-cal">http://bit.ly/pphw-cal</a>
Professor, Engineering Physics. ~ <a class="moz-txt-link-freetext" href="http://cnerg.engr.wisc.edu">http://cnerg.engr.wisc.edu</a>
Faculty Director, Advanced Computing Infrastructure</pre>
</body>
</html>