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. 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. 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. >> 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. > 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. Moving the burden of keeping them running from the person doing a core API change to the maintainer just because they are now deprecated and in staging makes no sense. That just serves to overload the maintainer. And it's not like I want to work on those drivers any more than anyone else. I'm simply trying to follow a process that allows for an orderly removal with some sort of ability for end users to have a chance to push back if they need to. I'm having a hard time understanding why this deprecation procedure should be so maintainer responsibility heavy. Regardless though, I'm almost certain not to follow this specific deprecation process again in the future because of how you are suggesting it should be handled. >> 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? > 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". -- Doug Ledford <[email protected]> GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
