RE: Upcoming libibverbs release

["Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

> 
> 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.
> 

Thanks Doug.  This last paragraph helps me visualize how it can work with a
libuberverbs process.

Steve.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html