RE: Upcoming libibverbs release

Steve Wise
2016-06-29T22:03:45Z

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