Re: Upcoming libibverbs release

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3355 bytes --]

On 06/29/2016 04:54 PM, Steve Wise wrote:
>> I think the concern here is being overstated.
> 
> I don't think it is being overstated.  It is my concern, and it is valid.
> However, after these discussions it has been alleviated to some degree.   It
> seems like some of the members of this discussion already have an understanding
> of how this would all work out.   But perhaps other provider maintainers need
> more details (obviously I did).

I can tell you how it worked inside Red Hat for me (I no longer handle
the internal builds, others do, so the methodology might have changed a
little bit), but whenever I got ready to do an update for a release, I
had these steps to complete on each package:

1) Download any new source tarball
2) Build/test locally.
3) Build in build system (all official builds must be built through the
build system, which strictly controls how the build root is created for
each build and what packages are installed in that build root to make
sure a package built out of our build system will actually install and
rebuild on a machine of the same release properly).
4) For packages that other package build against, I had to make sure the
new package was put into the build root of the build system so other
packages would get built against the new version and not the old version
of the package.
5) Then I had to make sure the package made its way into an errata so it
would actually make it to the end users eventually.  Because the
packages in the RDMA stack are so incestuously dependent on each other,
I used one errata for all of the RDMA stack packages.  This is in
contrast to the norm at Red Hat which is a separate errata per package.

Mainly because of the dependency nightmare of "have I built libibverbs
and is it in the build root? Yes...OK, which packages can I build
next..", I kept a spreadsheet around to help me keep track of which
packages were on which steps and let me see at a glance if I could even
move to the next step on a given package.  Putting all of the verbs
providers into the same package as libibverbs itself would reduce about
10 of those lines to a single line.  That would certainly make things
easier to track.  And going back to Jason's comments, it wouldn't really
slow down end user's access to the packages since most end users get the
packages from someone like Red Hat and they are all delayed until the
next release anyway.  But, it would be fairly easy to say that we can
have a policy that supra-minor point releases are a foregone conclusion
when a provider library needs an updates.  And just in case that point
isn't clear, let me put it this way:

libuberverbs->master branch - ongoing development
libuberverbs->x.y.0 - Ubervervs major release, major changes or features
present.  When you make this release, you create a verbs-x.y branch.
Primary development continues on master.
libuberverbs->x.y.z - Minor bug fixes to major releases.  Done on
verbs-x.y branch.  Even before bringing in providers, these are
typically used after a major release as bugs settle out.  After adding
providers, it would simply mean that a provider bugfix is an understood
sufficient cause for new minor point release.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]