[ewg] Distribution of userspace code for OFED-1.5

[Doug Ledford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/23/2009 11:13 AM, Tziporet Koren wrote:
> Alexander Schmidt wrote:
>> Hi all,
>>
>> some time ago a new model for providing code updates in userspace
>> libraries
>> was decided upon for OFED-1.5. In this model, the distributors of
>> userspace
>> libraries should upload release tarballs to directories on the ofed
>> server and
>> new code should be picked up from there.
>>
>> I haven't heard any news on this topic since OFED-1.5 development has
>> been
>> started and we have new code for the ehca library pending, so my
>> question is:
>> is this new process already established or should we continue with
>> sending out
>> git pull requests? I think the distributors were in favor of the new
>> model, so
>> maybe they have an opinion on this?

Yes, I certainly have an opinion ;-)  My issue is not so much with
tarballs versus git pulls as it is well defined releases.

If you read the various git how-to documents on the web, one of the
common "best practices" (ok, really it's more like "if you don't do this
you are a putz" things) is that once a public git repo has a tag, that
tag should never change.  So, if you have a git repo for, say, mstflint,
and you make a release of mstflint and tag it in the repo as version
1.4, then that tag, and the corresponding git tree associated with that
tag, and therefore the tarball created when you git export to tarball
from that tag, should *NEVER* change.  If you add some fixes later, you
should *NEVER* respin the tarball from HEAD instead of the release tag.
 If you want to respin a new tarball, you need a new release tag and
correspondingly a new version on the tarball.

So, how does one handle this when using git repos and wanting to pull
from head in order to get the latest fixes without going through a full
release cycle all the time?  There are two ways to do this (speaking
specifically of creating src rpms).

One is to create a new tarball from head, but don't name it
mstflint-1.4.tar.gz, name it mstflint-1.4-git-<short_commit_ref>.tar.gz
then create your src rpm with a n-v-r as such:

Name: mstflint
Version: 1.4
Release: 0.<incrementing_number>.git<short_commit_ref>

Every time you spin a new tarball, you replace the short_commit_ref with
the short reference to the head you spun from.  Also, every time you
spin a new tarball, you increase the incrementing number.  The point of
the incrementing number is that it ensures that when rpm tries to sort
the old package versus the new package, it will always sort the new one
as being newer and perform an upgrade without needing the force flag.
If you didn't have that there, then the git short commit ref would
randomly sort as being newer or older depending on the specific commit
refs.  It's also common to use the date instead of the short commit ref,
but it's not as precise in case someone wants to duplicate your tarball
by exporting from a copy of your git repo.  I should note here that the
0.<incrementing_number> method is usually used when doing prerelease git
src rpms.  This is so once the 1.4 release goes final, you can create a
src rpm that is just 1.4-1 and it will sort as being newer than all the
various git releases that you did.  If, instead, you are doing
post-release git tarballs, where the tarball is version + patches, then
you can actually shorten the src rpm n-v-r to just use Release:
<incrementing_number> and only reference the short commit ref in the
name of the tarball.

The second option (and is what we do internally with our kernel rpms
since they are stored and worked on in git, then exported to rpm format
for builds) is to pick a tag as a starting point.  So, in this example,
we would start from the official mstflint-1.4 tag and we would export an
mstflint-1.4.tar.gz archive.  Then, in order to pull in all the
additional fix patches, we have a script that gets the commit ref for
the tag of our tarball, then basically does a git format-patch
<tag_commit>.. so that we get all the patches from the tag to HEAD.  The
script then uses an rpm spec file template and inserts appropriate patch
lines in the spec file for all those patches.  In our case we hand
modify the version in the spec file for each official build, which is
why our 2.6.18 kernel is up to release version 155+.  This option has
the advantage of making it easy to tell exactly what patches have been
applied since the official release without having to inspect the git repo.

Regardless, the point of all this is that when someone downloads the
OFED-1.5-nightly tarball and unpacks it, then looks in the SRPMS
directory, they should be able to tell, just by looking at the n-v-r of
any given package, if it has changed from the previous OFED-1.5-nightly
tarball, and the version-release combination of any given package should
always sort in ascending order so that the newer package will be seen by
rpm as an upgrade from the previous package.

> We have not defined it yet since the decision was to first have feature
> freeze & alpha release and doing this change for the beta.
> 
> tziporet
> 
> _______________________________________________
> ewg mailing list
> ewg at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


- -- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpFLm8ACgkQQ9aEs6Ims9g73wCgiydabK8voDjG4jJKK+gMErEE
aRQAoNr0Fl4ZetWYzYT4nri00BavXbFQ
=wRhZ
-----END PGP SIGNATURE-----