On Oct 17, 2016, at 11:56 PM, Gilles Gouaillardet <gil...@rist.or.jp> wrote:
>
> Jeff,
>
> i have no strong objections against the new scheme.
> that being said, i think i like the current one better ...
> imho, the issue is the tag was put on a commit that is common to master and
> branch.
>
> i guess we did :
>
> git checkout master
> git tag v2.x
> git branch v2.x
>
> what if we had done instead :
> git checkout master
> git checkout -b v2.x
> git commit --allow-empty -m "forking the v2.x branch"
> git tag v2.x
I think you meant "git tag v2.x-dev" (you can't have the branch and tag name be
the same -- that's ambiguous).
This happened because we originally created ompi and ompi-release; the master
branch went to ompi, and the v2.x branch went to ompi-release. The "v2.x-dev"
tag went to the v2.x branch in ompi-release, on the commit that is the common
ancestor of both the master and v2.x branches. Meaning: this tag was not in
the ompi repo.
I.e., we didn't realize the problem until the v2.x branch was brought back to
the ompi repo (which was fairly recent). This put the "v2.x-dev" tag (much)
more recent than the "dev" tag, and therefore "git describe" on master shows
"v2.x-dev" instead of "dev".
The (abbreviated) tree looks like this (from git log --graph --decorate
--abbrev-commit --pretty=oneline --all --simplify-by-decoration):
-----
* 0a6c886 (origin/v2.x, v2.x) Merge pull request #2149 from hjelmn/v2.x_accumula
| * a659cb2 (HEAD -> master, origin/master, origin/HEAD, jsq/master) Merge pull
| | * a66f3e2 (origin/v2.0.x, v2.0.x) Merge pull request #2163 from hjelmn/v2.0.
| |/
|/|
* | ee86e07 (tag: v2.0.1) Merge pull request #1363 from jsquyres/pr/v2.0.1/fix-r
* | 0a4a5d7 (tag: v2.0.0) Merge pull request #1266 from jsquyres/pr/v2.0.0/news-
|/
* ec44a25 (tag: v2.x-dev) README: clarify OMPI's same-version requirements
* 84810b8 (tag: dev) Cover the remaining code paths for Java apps to define cl
-----
Notice:
- We originally had the v2.x branch in ompi-release, and made the v2.x-dev tag
there. When we migrated the v2.x branch back to ompi, it became evident that
the v2.x-dev tag is in the "wrong" location (i.e., it should have been at one
commit beyond ec44a25 on the v2.x branch).
- The v2.x and v2.0.x branches are currently both "git describe"ing their
relation to the v2.0.1 tag because we aggressively delayed making the v2.0.x
branch until we absolutely had to. Hence, the v2.0.1 tag is reachable by both
the current v2.x HEAD *and* the v2.0.x HEAD.
> pro: i guess that would have produced the "expected" behavior.
> cons: v2.x would be only on the v2.x branch, so the branch point is really
> the parent of the tag
>
> regardless we want to change the way we tag, could we simply sed the git
> describe output instead ?
> master : git describe | sed -e 's/v2.x-dev/master/g'
> v2.x: git describe | sed -e 's/v2.0.1/v2.x/g'
> v2.0.x: git describe | sed -e 's/v2.0.1/v2.0.x/g'
> or
> v2.x: git describe | sed -e 's/v2.0.1/v2.1.0a/g'
> v2.0.x: git describe | sed -e 's/v2.0.1/v2.0.2a/g'
My proposal with the (admittedly long -- but who cares?) timestamped filenames
is a recognition of:
- tags are heavyweight and eternal (i.e., we can't change them once they're
made)
- due to unforeseen circumstances, we haven't gotten the tags right so far
- even where the tags *are* right, "git describe" gives confusing output (e.g.,
the v2.0.x and v2.x tarballs)
So why keep using this mechanism?
But even more importantly: you're proposing output that *looks* like "git
describe" output, but *isn't*.
Meaning: you can't map your sed'ed string back to a unique place in the git
history in the same way that you can with "git describe" output. Yes, you
still have the git hash, but it won't be related to the tags in the history in
the same way that "git describe" output is. *** This will be incredibly
confusing! ***
Another way of looking at this: sure, we can sed the "git describe" output, but
that's effectively equivalent to using a different mechanism. And if we're
going to use a different mechanism, we shouldn't violate the Law of Least
Astonishment by making it look like the original mechanism.
The timestamp-based filename gives us a different that is easily human
readable, sortable, and tracked back to a specific location in the git history.
>> I propose changing them to the following format:
>>
>> openmpi-${BRANCHNAME}-${YYYYMMDD}-${SHORTHASH}.tar.bz2
>>
>> Here's what last night's tarballs would have looked like with that scheme:
>>
>> openmpi-master-20161017-bd1b6fe.tar.bz2
>> openmpi-v2.0.x-20161017-a66f3e2.tar.bz2
>> openmpi-v2.x-20161017-56991c6.tar.bz2
>>
>> Optionally, we could put a HHMM timestamp in there for finer granularity.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
