On Mon, Nov 02, 2015 at 10:14:06PM -0500, Doug Ledford wrote: > On 11/02/2015 07:49 PM, Greg Kroah-Hartman wrote: > > On Mon, Nov 02, 2015 at 07:02:04PM -0500, Doug Ledford wrote: > >>> 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. > >> > >> Yes. I get that. And I understand that. But because of Lustre, you > >> have made a global policy that effects all staging drivers without > >> legitimate cause, proudly broadcast that policy at a conference, even > >> answered a question from Christoph confirming that policy, and now in > >> this email thread where I object to that policy you say "It doesn't > >> really happen anyway, don't worry about it.' > > > > No, it's not "because" of lustre, it's been that way since day one when > > we started the staging tree. Christoph was just annoyed that someone > > was trying to tell him otherwise. And he is right. > > No, he's not. As I've already pointed out, the policy is only > appropriate for neglected drivers.
No, it's appropriate for all of drivers/staging/ and was what I ensured the rest of the kernel community when I created it many years ago. > I don't care if the policy was applied to everything in staging, > whether neglected or not, from day one. It was evidently bad from the > beginning. I'm calling it out. I've even provided justification for > calling it out. And I disagree, sorry. And as maintainer of this portion of the kernel, I don't want to go back on my word to the rest of the kernel community, that would be rude. > So far, your only response has been "That's the way it's always been, > and that's the way it is", which does nothing to justify the status quo > but stands only to argue that it is the status quo and therefore should > remain such. Inertia is a poor argument. My argument is, "No kernel developer should care about what is in drivers/staging/ as it is obviously code that is not in a mergable state, otherwise it would not be in this location." Now yes, we have started to use it to delete drivers, but that's now not really a good idea (see my other email about that.) If your code was in mergable state, then please take it out of staging now, but from what I have seen, that is not the case, so it needs to live here until it can get cleaned up properly. > >> But the person who quoted > >> you (Christoph) is the author of one of the API changes that *did* break > >> the RDMA drivers in the staging tree and he fixed them up when I asked > >> him to. Christoph then later quoted you and his interaction with you at > >> conference to indicate he didn't have to. > > > > He didn't have to. He was being nice. > > Again, I disagree. Fair enough, but that doesn't change the fact that he had no requirement to make this change. > > That's your job to fix them up > > if you want the code in staging. > > As I pointed out in an earlier email, allowing deprecated drivers to > simply break defeats the whole purpose of deprecating them in the first > place. Then we should just delete them from the tree, that makes things simpler for everyone involved. > >> And what I'm telling him, and > >> you since you are the person he's quoting to justify not fixing up > >> things, is that I don't care what you say, when it comes to those > >> drivers that I moved into staging, if he wants me to take his core > >> patches, then he needs to make sure they don't break those drivers I > >> moved into staging. > > > > Nope, not true. If you don't like this, I'll gladly just delete the > > drivers from staging, sorry. > > Maybe you should be more clear about your intention here. Under > precisely which actions of mine will you resort to retaliatory deletion > of code, and which code? If you insist to other kernel developers that they have to fix up code in drivers/staging/ I will not accept that, and will ask for that code to be removed as that is not how this portion of the kernel tree works, sorry. > > You don't get a "free ride" in staging at > > all. > > I'm not sure what you are calling a "free ride". Certainly, if what I > asked Christoph for is a "free ride", then drivers in the core kernel > get "free rides" all the time. As such, I didn't ask for anything > unusual or out of the ordinary. Because of the reasons I stated in my > previous email, I asked for the drivers I moved to staging to be treated > the same as any other driver would be. Equal treatment is hardly a > "free ride". drivers/staging is not "equal" to the rest of the kernel, I think that is the misunderstanding here. hope this helps, 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
