> > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
