Re: kdbus refactoring?

[Andy Lutomirski]

On Mon, Nov 9, 2015 at 9:07 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Nov 09, 2015 at 05:02:45PM +0000, MÃns RullgÃrd wrote:
>> Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes:
>>
>> > On Sun, Nov 8, 2015 at 3:30 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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 <gregkh@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/