On Tue, Sep 8, 2015 at 8:08 PM, Doug Ledford <dledf...@redhat.com> wrote:
>
> With a comment that said "I can carry this merge forward, no further
> action is necessary on your part". That combined with my lack of deep
> internal knowledge of what it is that Stephen is doing made me go "Ok,
> he says don't do anything, so I won't change it."
So quite frankly, Stephen does a really good job at merging and most
of his merges are very on point. He's been doing a lot of them as part
of linux-next, and has seen more conflicts than just about anybody
else.
But I think to him it's mostly just an issue of "get the right end
result". I don't think he goes: "this merge conflict is a result of a
breakdown of the development process".
Conversely, to me, one of the main reasons I want to do those merges
is exactly because I think conflicts are more about the development
process issues than about "just getting the right end result". Yes,
obviously I want to get the rigth end result too, but I very much
react to how/why the conflict happened in the first place. The end
result is _almost_ secondary, although 99% of the time the primary
issue doesn't really even raise its head.
So I'm upset not because the conflict is hard to resolve (it isn't),
but because I feel this was really badly handled.
Yes, the fact that Mellanox people sent two different patches to two
different maintainers that did the same thing in two different ways is
odd. Matan and Jiri are cc'd, and I think that whole thing just smells
really bad.
But at the same time, I expect more of maintainers, and I don't see
any sign that David and the networking people were notified about the
_other_ patch to _their_ subsystem.
The fact that you weren't aware of the other patch in the networking
subsystem is kind of to be expected. You're not the network
maintainer, so why would you? But exactly because you're not the
networking maintainer, I would have expected you to check with him
when you apply patches to generic networking code.
This time it conflicted, and I noticed, and I went "this is not how
kernel development is supposed to go".
But say that the other networking patch hadn't even existed: in that
case I *still* shouldn't have gotten a patch to net/core/dev.c from
you without any sign that David had ack'ed it (or at the very least
been notified, even if he hadn't reacted).
See?
Linus
--
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
