BTW, I should point out that the proposed scheme does *not* create
significantly longer filenames.
Actual:
* master: openmpi-v2.x-dev-3019-gbd1b6fe.tar.bz2 (39 chars)
* v2.0.x: openmpi-v2.0.1-101-ga66f3e2.tar.bz2 (36 chars)
* v2.x: openmpi-v2.0.1-203-g56991c6.tar.bz2 (36 chars)
Proposed (including HHMM):
* master: openmpi-master-201610172100-bd1b6fe.tar.bz2 (44 chars)
* v2.0.x: openmpi-v2.0.x-201610172115-a66f3e2.tar.bz2 (44 chars)
* v2.x: openmpi-v2.x-201610172130-56991c6.tar.bz2 (41 chars)
> On Oct 18, 2016, at 10:19 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com>
> wrote:
>
> 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
--
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
