On Tue, Nov 03, 2015 at 11:59:02AM -0500, Chuck Lever wrote: > > > On Nov 2, 2015, at 6:37 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> > > wrote: > > > > On Mon, Nov 02, 2015 at 06:20:40PM -0500, Doug Ledford wrote: > >> 1) Aging, but working, drivers that will be removed in the future. > >> Since we no longer have a deprecation mechanism, I was informed that the > >> normal procedure now is to move the driver to staging for a while and > >> then remove it permanently on a future schedule. This provides an > >> orderly removal process. But, if you make it so that random people can > >> break the driver with no responsibility for fixing up their breakage, in > >> contrast to the entire rest of the kernel, then you eliminate that > >> orderly removal process and turn it into a completely non-deterministic > >> and chaotic removal process. So, no, if that's how it will be handled, > >> I will move the deprecated drivers back to the main rdma tree and time > >> them out and perform the orderly removal myself. > > > > So you have what, one more kernel release before these are deleted? > > Odds are, nothing is going to be broken so badly that a simple patch > > will not fix up before they are removed. So don't worry about this. > > > > And why would you want a developer wasting time on fixing up these > > drivers if they are about to be deleted anyway? Obviously no one even > > uses them, otherwise they wouldn't be about to be removed. > > I understand the stated policy, but I was recently > bitten by it. I got dinged by the kbuild robot when I > made a change that broke something in staging. I was > caught between the staging policy and the guidelines > about fixing kbuild nits before a merge window. > > My change was in the IB core, but the breakage was in > Lustre. Their fix (which was quick because I had warned > them in advance) was substantial, and not something I > could have provided myself. > > If the bits in staging are truly to be ignored, then > the kbuild robot shouldn’t warn about new staging > breakage. Or the warning messages should state that > fixing said breakage is optional.
You are always free to ignore the results of the 0-day bot for stuff like this if you want to, that's your choice, it's just informing you of the results of the build. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
