Re: [hwloc-devel] nightly snapshot tarballs now available

[Brice Goglin]

Le 27/09/2013 22:44, Jeff Squyres (jsquyres) a écrit :
> Ok, the infrastructure is now updated.  I've generated the first snapshot 
> tarballs in http://www.open-mpi.org/software/hwloc/nightly/.  Nightly 
> snapshots for <=v1.6 have all been removed.
>
> Git is fully open for business.  Enjoy.
>

Thanks!

A couple things:
* Did you rebuild the secondary git repo of the debian/ "submodule"? We
said we would store it on the side of the main hwloc repo. It can go
under github too, but no need to integrate it with trac or so.
* I am looking at updating
http://www.open-mpi.org/projects/hwloc/svn.php, I will likely remove a
lot of things from there
* what about
https://git.open-mpi.org/trac/hwloc/wiki/TracSVNCommitMessages, is
everything valid after a s/SVN/GIT/ ?
* Do you see any other page to update?

Brice

[hwloc-devel] nightly snapshot tarballs now available

[Jeff Squyres (jsquyres)]

Ok, the infrastructure is now updated.  I've generated the first snapshot 
tarballs in http://www.open-mpi.org/software/hwloc/nightly/.  Nightly snapshots 
for <=v1.6 have all been removed.

Git is fully open for business.  Enjoy.

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

Re: [hwloc-devel] git / nightly builds

[Jeff Squyres (jsquyres)]

On Sep 27, 2013, at 9:43 AM, Brice Goglin  wrote:

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

K.

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

E... let's cross that bridge when/if we need to.  :-)

>> 2. With SVN, adding the r number in the tarball version was sufficient to 
>> observe ordering of the tarballs.  For example:
>> [snip]
>> 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?) ?

There are actually 2 scripts:

contrib/dist/make_dist_tarball
contrib/nightly/make_snapshot_tarball (currently called create_tarball.sh)

The former works largely as it did before: it'll make hwloc-.tar.*.

The latter is being heavily updated to basically use "git describe".

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

Re: [hwloc-devel] git / nightly builds

[Samuel Thibault]

Jeff Squyres (jsquyres), le Fri 27 Sep 2013 15:36:33 +0200, a écrit :
> 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'm fine with it.

Samuel

Re: [hwloc-devel] git / nightly builds

[Brice Goglin]

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 g...@github.com: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

[hwloc-devel] git / nightly builds

[Jeff Squyres (jsquyres)]

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'm thinking that back-porting further is useless; we should just stop making 
nightlies for all the older branches.

To clarify: with SVN, we still checked all the older branches every night and 
would make a new tarball if there was ever a change.  We never made changes in 
those older branches, so we never made new nightlies.  But we *would have*, if 
a change had every been committed on those branches.

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 g...@github.com: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?

(note: I'm still mucking with the final tag names, so some of the above may 
change slightly)

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