> 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. >> 2) New drivers (one currently, one other one submitted but not yet >> pulled in) under active development but which need specific things fixed >> up. These have people already working on them full time. They were >> submitted to the staging tree with a specific TODO in order to get out. >> If you then break that driver and force the driver author to fix it, >> you have in essence changed the TODO list. That means you now have a >> moving goal post scenario. > > Again, this shouldn't be taking you all that long to get out of staging, > right? And again, the number of api changes that cause breakage are > usually very minor, if they happen at all (remember, this is a > theoretical, not what usually happens.) And a driver in this state > doesn't deserve to be in the "real" portion of the kernel, so you can't > merge it anywhere else, so overall it still benifits being in the > staging tree, so a few minor breakages every once in a while should be > easy for you to fix up, _if_ they happen. > > Again, I don't know of any recent api change that has caused any > problems in a long time, but the VFS developers really hate having to > touch lustre code, and I don't blame them, so sometimes that codebase > breaks. That will not affect your drivers at all, so I wouldn't worry > about this. > > So relax, this isn't going to be an issue, or if it is, you can easily > handle it, it is no different from any other tree-wide api change that > happens. > > 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 — Chuck Lever -- 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
