On Tue, Apr 21, 2015 at 01:09:42PM +0200, Greg Kroah-Hartman wrote:
> Vs. being offensive quickly like you started out with? :)
Of course you'll come back with an attack. Polemical tactics or what is
this called?
> And I've kept asking for review, and the people who have reviewed it,
> their issues have been addressed.
>
> But to somehow say "it's insecure because it is a lot of code" is
> unhelpful and flat out mean.
Well, so other people are reviewing it now. And it clearly needs more
review, people suggested even sitting down and talking face to face. So
we can put the mind-boggling upstreaming rush on hold now, right? Until
all the doubts have been cleared and there's general agreement.
And if you tell me that this current state of the affairs is general
agreement, then I can surely understand the NAKs.
> We add chunks of code large than this to the kernel all the time. For
> core infrastructure pieces. Asking for people to review it, and discuss
> it is normal, nothing is happening different here.
13KLOC in one go without a single Reviewed-by? I don't think so.
> In the end, not everyone reviews all of the code, that's normal. I see
> chunks get merged all the time and I go "what? That's crazy? Who would
> want a virtual machine as their networking packet parser?" But given
> that the maintainer of the subsystem acked it, and has agreed to
> maintain it, I trust them to do the right thing. That's how kernel
> development works, on trust.
You got an argument about that already: we're talking core code here,
not some driver or a packet parser which is not used by *everything*.
> And that's the core issue here, trust.
>
> You are the only one to bring this up in the thread, but I feel it's the
> underlying theme. You act as if you don't trust us, the developers, to
> be doing the right thing here. If so, great, please, let's talk about
> it.
Well, maybe I'm the only one to say it...
A lot of people are simply tired of the talk-people-into-submission
tactics and can you blame them?!
> Trust is about not always getting everything right, but trust that the
> people involved will be around to fix it if something is wrong. And
> that the people involved are actually working toward something they see
> is valuable and needed in an honest way.
Yeah, like the time I trusted to open a bugzilla to fix the "debug"
parsing on the command line and systemd hijacking it. After that
debacle, the trust container here is empty. That ship has sailed, sorry.
> If you don't trust me, great, say it. If you don't trust David, Daniel,
> and Djalal, great, say so, and we can work on addressing that issue.
>
> If you don't trust the code, wonderful, please let me know that and show
> what is untrustworthy about it, again, as Al and Andy have done so. Let
> us address it that way, as has been done so thanks to Al and Andy's
> review.
>
> But to do drive-by potshots in an email thread, just because you somehow
> don't like the color of the bikeshed, without having every looked inside
> the bikeshed to see what it is doing there, is completely unfair and a
> unreasonable and totally unproductive.
Yeah right, like you don't do that. There's another one of your attack
the opponent tactics. Oh well, I *trust* you to do *that*! :-D
Let me give you a similar comeback: "But I'm on CC!" :-P
> greg "read the code luke" k-h
Oh but I'm looking. And I don't really like what I'm seeing. But to get
back to Richard's statement: it is a *lot* of code so I, and probably
everyone else too, can't just drop everything and jump on 13KLOC code.
It needs time.
So let's stop the polemics and agree that it is not time to upstream
this thing yet. We should instead get down to business and give it a
good long look until Reviewed-by's start happening.
Agreed?
Boris "Darth Maul".
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
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/
