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 <nietham...@hlrs.de> 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)" <dgood...@cisco.com>
> To: "Development list for the MPI Testing Tool" <mtt-de...@open-mpi.org>
> 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)" <jsquy...@cisco.com> 
>> 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 
>>> <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

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" <gilles.gouaillar...@iferc.org>
To: "Development list for the MPI Testing Tool" <mtt-de...@open-mpi.org>
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)" <dgood...@cisco.com>
> To: "Development list for the MPI Testing Tool" <mtt-de...@open-mpi.org>
> 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)" <jsquy...@cisco.com> 
>> 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)
>

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

2014-06-27 Thread Christoph Niethammer
+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)" <dgood...@cisco.com>
To: "Development list for the MPI Testing Tool" <mtt-de...@open-mpi.org>
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)" <jsquy...@cisco.com> 
> 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 
>> <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

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

2014-06-26 Thread Jeff Squyres (jsquyres)
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: 
http://www.cisco.com/web/about/doing_business/legal/cri/



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

2014-06-24 Thread Gilles Gouaillardet
+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] MTT: let's use git tags

2014-06-24 Thread Jeff Squyres (jsquyres)
The topic came up today that MTT sometimes has bugs, particularly w.r.t. 
ongoing MTT development.

It seems like we should use git tags to let the OMPI/testing community know 
which tag they should be using (vs. HEAD).

To that end, I have created a "v3.0.0" tag that exists before the controversial 
set of commits I pushed the other day -- e12386e.  Assumedly, when we fix 
whatever problem Mellanox is setting with commits beyond e12386e, we can call 
that "v3.0.1", or some such, and ask everyone to move up to it.

So those who need stability should stick back at tags, and those who want to 
help with development can be at the HEAD.

How does that sound?

If that sounds ok, I'll ask the OMPI test community to git checkout v3.0.0.  
And in the future, we'll ask the OMPI test community to update to the next 
relevant tag, etc.

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