Re: [MTT devel] MTT: let's use git tags

2014-06-30 Thread Jeff Squyres (jsquyres)
Dave and I finally got to talk about this.

It seems like the simplest/easiest approach is to have a fast-forward-able 
"stable" branch.  I'll set this up and push to github.


On Jun 27, 2014, at 12:11 AM, 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.
>> 
>> (...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 
>>>  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: 
>> 

Re: [MTT devel] MTT: let's use git tags

2014-06-30 Thread Christoph Niethammer
Hello,

A fast forward merge does not create a single merge commit but takes all 
commits and applies them to the current branch.[1]
So this will do what Jeff intended without the necessity of deleting and 
recreating a static tag or editing version numbers in update scripts. ;)

Regards
Christoph

[1] http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html


- Original Message -
From: "Gilles Gouaillardet" 
To: "Development list for the MPI Testing Tool" 
Sent: Monday, June 30, 2014 4:06:34 AM
Subject: Re: [MTT devel] MTT: let's use git tags

Jeff,

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

Cheers,

Gilles


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.
>>
>> (...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 
>>>  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