On Tue, Sep 06, 2016 at 12:34:05PM -0600, Jason Gunthorpe wrote: > On Tue, Sep 06, 2016 at 12:01:02AM -0700, Christoph Hellwig wrote: > > On Sun, Sep 04, 2016 at 11:18:02AM +0300, Sagi Grimberg wrote: > > > I think that having a maintainer per provider makes perfect sense > > > and as long as you Jason (or anyone else) are committed to merging it > > > all together and produce standard releases we are pretty much set. > > > > > > What I think it missing is a release schedule, stable fixes > > > methodology and merge cycles. I think once we can agree on that > > > a lot of the concerns will be addressed. > > > > So let's keep the maintainers as-is, e.g. each previous project > > keepts it's own maintainer similar to driver maintainers in the > > kernel. > > This is certainly what I imagined. Nobody else has the domain > expertise for these sub components. > > However, there is a lot of work just to keep everything ticking over, > compilers change, build tooling changes, distros need hand holding, > boring patches need accepting. That is where all maintainers should see > value in this approach. > > > We'll add Jason as a global maintainer for the build system or any > > non-controverial fixes and we should be much better setup than the > > current situation. > > I was hoping a team including Doug would handle the general patch > stream. Most of the patch flow today is for libibverbs and related > anyhow. If Leon wants to handle the boring patches and provider pulls > then that seems like a good combination. It is not that I'm over-excited about it, just I think that someone needs to do it to keep RDMA stack moving forward. I personally see the whole RDMA stack as one entity and don't want to separate it to kernel vs. user. > > > Combine that with kernel-like major releases plus minor release on > > demand and we should have a winning setup. > > I think the release cadence should be driven more by the distros, but > following the kernel cadence is a sane place to start. > > Not much point in making a release if nobody is out there wanting to > use it. I expect the distros will want to go to a more stable > maintenance footing so we many want to offer to co-maintain a public > LTS branch... Release -> put a tag every X-days. For example Linus's tag will close patch acceptance and 1-2 weeks after that, new tag will be added. In such way everyone will know exactly what and when new version will be available. Changelog can be generated from git history, participation in rawhide/testing/tumblweed will ensure that packages are constantly built. At this point of time I don't see any reasons to manage stable branches, it is much easier and convenient to ensure that master is always buildable and ready to ship. It will be worth to make a split for libibverbs2.0 when we will work on ABI. > > > Now we just need to bikeshed on a good name for the repo, because > > honestly rdma-plumbing sucks as a name :) > > Let the painting commence! > > Jason > -- > 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
Attachment:
signature.asc
Description: PGP signature
