On Mon, Nov 13, 2017 at 08:53:19AM +0100, Nicolas Morey-Chaisemartin wrote: > > > Le 10/11/2017 à 21:24, Leon Romanovsky a écrit : > > On Fri, Nov 10, 2017 at 06:36:28PM +0000, Davis, Arlin R wrote: > >>> I agree there is a big need for that. Currently reviewing all the patches I haven't > >>> read (only 1000 mails to go...) to see if they need to be backported on top on > >>> rdma-core 15 for the next SLES. > >>> I'd gladly help maintaining this as I'm spending time on it anyway. > >>> I'll leave wiser people debate and ready a doc on how this should be done > >>> though :) > >>> > >>> Nicolas > >> Thanks Nicolas. > >> > >> Ok, I am not sure what details the rdma-core maintainers are looking for in a document. Let me start the discussion with the following: > > More or less, you wrote everything that I expected, just need to post it > > as a patch so I can apply it to rdma-core. > > > > The thing which is important to me is how long that stable will be maintained and how often they will be opened, > > I don't want to see 12 stable branches after 3 years of running rdma-core. It releases every 2-3 months, so theoretically > > we can find ourselves creating stable branches after every release (4 per year). > > > > Thanks > > > >> Stable Branch Release > >> > >> Current Maintainer: Nicolas Morey-Chaisemartin <NMoreyChaisemartin@xxxxxxx> > >> > >> Upstream rdma-core is considered stable after each mainline release. Branched stable releases, off a mainline release, are on as-needed basis and limited to bug fixes. All bug fixes are to be backported from mainline and applied by stable branch maintainer. Branched stable releases will append an additional release number (e.g. 15.1) and will ensure that Travis CI reports a successful build. Mention the frequency of stable releases or keep it "as is" cadence? > >> > >> See versioning.md for setting package version on a stable branch. > >> > >> Arlin > >> > >> > >> > > > Resent because Thunderbird screwed up my content. > > > What would make sense IMHO would be to have people submit their patches to stable branches through a github issues. > Each issue should be tagged in all the main/stable release it is in and contains a SHA1 to a patch from master that contains a fix. > I personally against such close integration with github and creating two different places for communication (ML and github), but as Jason said, the core team has no plans to manage it and it will be your decision on how you will manage it. Right now, the gihtub issues are disabled in rdma-core, because we didn't want people open bug reports there instead of posting to the ML. Thanks
Attachment:
signature.asc
Description: PGP signature
