RE: Upcoming libibverbs release

Steve Wise
2016-06-29T19:15:46Z

>
> > I have a concern about the loss of control that might happen. For example,
now
> > I can release a new libcxgb4 whenever it works for me. I wouldn't want to
give
> > that up and require everyone's blessing/coordination to release bug fixes
that
> > are completely in libcxgb4. How can we handle this with a single repo for
all
> > the provider libs?
>
> I think you start by realizing that nobody uses your git releases
> anyhow.
>

Not true. RedHat, for one, does.

> Everyone uses either a distro or OFED release and those are already
> co-ordinated outside your control.

I don't know who "everyone" is, but at least some of the distros get the
libcxgb3/4 packages from releases I publish and announce on linux-rdma. Chelsio
recommends to RedHat exactly which libcxb release to pull in for each of their
OS releases. They are not necessarily tied to an OFED release either. Ditto
for SUSE, although they may still take from OFED packages.

>
> Changing the place the distro gets the patches from makes no real
> difference to you or your users. However, it does make the distro's
> life simpler by having only one place to look for patches.
>

>From what I've experienced, the distros don't take patches for libraries at all.
They take discreet releases that are published by the maintainer of that
library. Doug, correct me if I'm wrong. But that is how things are working
today at least for libcxgb*. This is different from the kernel, where distros
pull in commits for fixes.

> I'd expect that provider-only patches would have a fast path into the
> combined git head, since they don't really need any consensus, and
> that is enough to get them into the backport/release cycle for the
> above channels.
>

Yes, and I'm asking that we figure this out before we cram all these libraries
into one git repo. And again, currently I think distros pull release tarballs
and not from any git trees for the rdma provider libraries...

Steve.