On Mon, Nov 9, 2015 at 9:07 AM, Greg KH <gre...@linuxfoundation.org> wrote: > On Mon, Nov 09, 2015 at 05:02:45PM +0000, Måns Rullgård wrote: >> Andy Lutomirski <l...@amacapital.net> writes: >> >> > On Sun, Nov 8, 2015 at 3:30 PM, Greg KH <gre...@linuxfoundation.org> wrote: >> >> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote: >> >>> On Sun, Nov 8, 2015 at 10:35 PM, Greg KH <gre...@linuxfoundation.org> >> >>> wrote: >> >>> > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote: >> >>> >> Hi all, >> >>> >> >> >>> >> after reading on the removal of kdbus from Rawhide[1] I've searched >> >>> >> the mailinglist archives for more details but didn't find anything. >> >>> >> So, what are your plans? >> >>> >> >> >>> >> [1] >> >>> >> https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html >> >>> > >> >>> > As that link said, based on the result of the code being in Rawhide, it >> >>> > is now being reworked / redesigned. The result will be posted for >> >>> > review "when it's ready". >> >>> >> >>> If you rework/redesign something you have to know what you want to >> >>> change. >> >>> That's why I was asking for the plan... >> >> >> >> Since when do people post "plans" or "design documents" on lkml without >> >> real code? Again, code will be posted when it's ready, like any other >> >> kernel submission. >> > >> > I ask for feedback on ideas and designs on a fairly regular basis. I >> > even frequently get valuable feedback :) >> > >> > I would like to think that the kernel community would have something >> > of value to add to the process of designing and implementing a major >> > new IPC mechanism. >> >> The "trust us, we'll show it when it's ready" attitude reminds me of the >> controversial TPP and TTIP negotiations. > > Ok, that's just trolling, cut it out. > > When something is even in the "hey look, it works, here's the big > changes from last time", we will of course post it, but right now, > things are being totally revisited based on the feedback we have > received so far. Give people a chance to recover from conferences and > then get back to work... >
I hate to say this, but this approach to receiving feedback makes me really dislike the process. I read a fairly large fraction of the kdbus code. I found what I perceived to be issues, and I spoke up. I was told for quite a while that the authors disagreed that the issues I found were issues and that my assessment of the security aspects of the code was correct. Now the submission has been withdrawn (because of feedback received so far? from me?) and there will apparently be a new submission out of the blue, allegedly based on feedback. As a developer, I'm willing to ask for feedback on ideas and to ask for feedback on code. In many cases, I've gotten (correct!) feedback telling me that my design is wrong or needs major changes. I *always* try to answer such feedback respectfully and, if the reviewers are right (which they usually are), I won't keep shoving code they don't like in their face. In fact, IIRC I got my start as a serious x86 developer when I wrote some code and tglx told me that the way I designed it was unacceptable for upstream. In response, I thought about what the issues were, asked some questions, and rewrite the majority of the code. I think I learned a lot from the process, and the code was vastly improved as a result. If I'd sent substantially the same patch series three or four more times and then declared that I was withdrawing it without commenting directly on what I'd changed, I really doubt that anyone would have taken my next submission seriously. Please understand that kdbus' approach to receiving feedback is very off-putting. Fortunately the vast majority of kernel developers receive feedback for graciously and transparently, because otherwise I'd probably just never review anything. Frankly, if I were in the chain of people through whom the kdbus code would flow to an eventual home in Linus' tree, I would just say that the developers have used up my patience as a reviewer and the onus would be on the developers to demonstrate that it's worth my time to continue thinking about the code. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
