Open MPI logo

MTT Devel Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [MTT devel] MTT: let's use git tags
From: Jeff Squyres (jsquyres) (jsquyres_at_[hidden])
Date: 2014-06-30 18:08:15


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 <niethammer_at_[hidden]> 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)" <dgoodell_at_[hidden]>
> To: "Development list for the MPI Testing Tool" <mtt-devel_at_[hidden]>
> 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)" <jsquyres_at_[hidden]> 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.gouaillardet_at_[hidden]> 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-devel_at_[hidden]
>>> 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
>> jsquyres_at_[hidden]
>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>> _______________________________________________
>> mtt-devel mailing list
>> mtt-devel_at_[hidden]
>> 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/0639.php
> _______________________________________________
> mtt-devel mailing list
> mtt-devel_at_[hidden]
> 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/0640.php
> _______________________________________________
> mtt-devel mailing list
> mtt-devel_at_[hidden]
> 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/0642.php

-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/