What i meant by "less error prone" is "you use the stable branch by
default" so you do not checkout the dev/unstable
branch by default.

as you pointed, the level/frequency of MTT development is fairly low,
my idea would be to create a "dev" branch, and when the state of the dev
branch is "production ready", simply do a

git checkout master
git merge dev

that being said, i am far from mastering git and i cannot judge the pros
vs cons of this (merge) versus the fast forward
approach pointed by Christoph



On 2014/06/27 16:11, Christoph Niethammer wrote:
> +1, for a stable branch which is *fast forwarded* to master when changes are 
> confirmed to work.
> PS: Tags are intended to be static and not moved around in git as Dave says, 
> instead you can sign them using gpg fortifying them even more. ;)
> ----- Original Message -----
> From: "Dave Goodell (dgoodell)" <>
> To: "Development list for the MPI Testing Tool" <>
> Sent: Thursday, June 26, 2014 2:47:35 PM
> Subject: Re: [MTT devel] MTT: let's use git tags
> Published Git tags are *not* movable (by design). You're better off making it 
> a branch that you treat like a tag, if that's your desire. Even then, you 
> might confuse someone who is less familiar with Git in some cases if you move 
> that branch around.
> -Dave
>> On Jun 26, 2014, at 6:06 AM, "Jeff Squyres (jsquyres)" <> 
>> wrote:
>> 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.
>> ( 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 
>>> <> 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
>>> Subscription:
>>> Link to this post: 
>> -- 
>> Jeff Squyres
>> For corporate legal information go to: 
>> _______________________________________________
>> mtt-devel mailing list
>> Subscription:
>> Link to this post: 
> _______________________________________________
> mtt-devel mailing list
> Subscription:
> Link to this post: 
> _______________________________________________
> mtt-devel mailing list
> Subscription:
> Link to this post: 

Reply via email to