Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] git / nightly builds
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2013-09-27 09:43:56


Le 27/09/2013 15:36, Jeff Squyres (jsquyres) a écrit :
> I'd say that git and the new Trac are now fully open for business. I might still do some shifting around of tags (see below), but otherwise, I think everything is just about ready.
>
> I'm revamping make_dist_script and the nightly build script; I should finally be able to commit those today, if all goes well. However, I had to make some changes to VERSION and some other surrounding infrastructure to make it all work. Specifically: git just does some things *differently* than SVN, so it required some changes in the way that hwloc does things, infrastructure-wise.
>
> Two things:
>
> 1. I'm not excited about back-porting these changes all the way back to hwloc-1.0 just so that we can make nightly tarballs for these branches which aren't used any more. I'm thinking that I should definitely make these changes for master and the v1.7 branch. Should I also do the v1.6 branch?

I don't think so. I am planning to only update the regression testing
for v1.7 as well.

BUT what if the stable OMPI 1.6 needs a hwloc fix? Should we keep the
hwloc v1.5 branch open?

> 2. With SVN, adding the r number in the tarball version was sufficient to observe ordering of the tarballs. For example:
>
> hwloc-1.8r1234.tar.bz2
> hwloc-1.8r1240.tar.bz2
> hwloc-1.8r1255.tar.bz2
> ...etc.
>
> With git, we only have a hash number. So there's no obvious ordering of the tarballs. For example:
>
> hwloc-1.8git11223344.tar.bz2
> hwloc-1.8git00aa3344.tar.bz2
> hwloc-1.8git99aa2277.tar.bz2
> ...etc.
>
> However, there is "git describe" functionality which, in our case, can show you how many commits you are beyond a given tag. For example, I added a "dev" tag on the master branch for the first pure-git commit (i.e., 1 beyond the last SVN commit). For example:
>
> $ git clone git_at_[hidden]:open-mpi/hwloc.git
> ...clone completes successfully...
> $ cd hwloc
> $ git checkout master
> $ git describe --always
> dev-3-g51efdd1
>
> Where the "3" represents that we're 3 commits beyond the "dev" tag. The "g" just means "git", and the "51efdd1" is the hash of that commit.
>
> Hence, if we use that as our version string, we get tarballs named something like this:
>
> hwloc-dev-3-g51efdd1.tar.bz2
> hwloc-dev-10-gf50a385.tar.bz2
> ...etc.
>
> For the master branch, I think that's fine. However, note that ***THIS IS DIFFERENT THAN WHAT WE HAVE PREVIOUSLY DONE ON RELEASE BRANCHES!***
>
> For example, if you checkout the v1.7 branch:
>
> $ git checkout v1.7
> $ git describe --always
> hwloc-1.7.2-4-g3a6f84c
>
> *** NOTE THE DIFFERENCE HERE:
>
> a) The last SVN nightly snapshot on the v1.7 branch was named
> hwloc-1.7.3rc1r5779.tar.bz2.
> b) The first git nightly snapshot on the v1.7 branch will be named
> hwloc-1.7.2-4-g3a6f84c.tar.bz2.
>
> Note "1.7.3rc1..." vs. "1.7.2...". I.e., the git name will say "we're X commits beyond the 1.7.2 tag", but the old SVN name was "we're at this *upcoming* version".
>
> I think that this is ok (other projects use this "git describe" kind of behavior for their nightly snapshots), but this is a change from what we used to do, so I wanted to call it out specifically.
>
> Are you guys ok with this?
>

That'll work for me.

What about when we are actually doing a release where we don't want a
git-describe suffix ? Does the above apply to contrib/make_dist_tarball
in general? Or only to when it runs at night (in make dist only?) ?

Brice