[ewg] Distribution of userspace code for OFED-1.5

[Tziporet Koren]

Doug Ledford wrote:
> 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.
>
>   
>
This is a good method and we will adopt it.

Tziporet