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 GPG KeyID: 0E572FDD