I've thought about this a little, and I'm still inclined to use the simple/lazy 
method of tags on master.  Some random points, in no particular order:

1. master should always be for development, IMHO.  If we start using a 
multi-branch scheme, then the branches should be for releases, etc.

2. MTT has always been distributed by VCS; we've never made discrete 
distributions (e.g., a tarball).  As such, I'm comfortable labeling it as a bit 
"different" than how most other software is delivered -- e.g., using git tags 
on master is "good enough".

3. The level/frequency of MTT development is fairly low; it would be good to 
keep the bar as low as possible for amount of work required to deploy a new 
feature to the OMPI community for MTT testing.  Meaning: a new feature or bug 
fix pops up in MTT every once in a while -- we generally don't have commits 
that are being developed and merged to a release series in an out-of-order 
fashion.  So doing a few commits for a new feature/bug fix and then tagging the 
result is fine/good enough.  If there *are* interleaved commits of multiple new 
features/bug fixes, we can simply wait until all are done before tagging.

4. I realize this scheme is not as flexible as a release branch (where you can 
merge new features/bug fixes out of order), but the level of MTT development is 
so low that I'd prefer the slightly-simpler model of just tagging (vs. 
merging/etc.).

5. I'm not sure how using a release branch is less error-prone...?  I 
understand git branching is cheap, but if we have a separate branch, then we 
either need to remember to cherry-pick every commit we want or we have to 
continually merge from master->release_branch.  Seems like more work/steps to 
follow, and therefore more error-prone.

6. The point about not being able to automate getting the latest stable MTT is 
a good one.  How about using numerical tags just to delineate our intended 
"release" points, but also have a moveable tag, e.g., "ompi-mtt-testing" that 
will always point to the latest "release" that we want the OMPI MTT test 
community to use?  That way, you can always "git checkout ompi-mtt-testing" to 
get the latest/greatest.

(...to that end, I've created/pushed an ompi-mtt-testing tag and pointed to the 
same place as v3.0.0)



On Jun 24, 2014, at 8:30 PM, Gilles Gouaillardet 
<gilles.gouaillar...@iferc.org> wrote:

> +1 for using branches : branch usage is less error prone plus git makes
> branching unexpensive.
> 
> as far as i am concerned, i'd rather have the default master branch is
> the for the "stable" version
> and have one branch called devel (or dev, or whatever) :
> - git clone => get the stable (aka master) branch by default (safe by
> default)
> - if you use the devel branch, one can only assume you know what you are
> doing ...
> 
> That being said, tags on the master branch is a good practice
> 
> Cheers,
> 
> Gilles
> 
> On 2014/06/25 2:33, Christoph Niethammer wrote:
>> As an alternative idea: What about using branches to mark "stable" and 
>> "development"?
>> Tags are for fixed versions and so users will not receive updates unless 
>> they update their update scripts manually?!
>> When "development" is stable just merge into "stable".
> 
> _______________________________________________
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/mtt-devel/2014/06/0636.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Reply via email to