On 9/9/2015 11:09 AM, Matan Barak wrote:
On 9/9/2015 9:41 AM, Jiri Pirko wrote:
Wed, Sep 09, 2015 at 05:33:28AM CEST,
[email protected]:
On Tue, Sep 8, 2015 at 8:08 PM, Doug Ledford
<[email protected]>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.
It's not that odd. I'm not checking rdma tree. I work with net-next/net
tree only when I do net patches. I wasn't aware of Matan's patches,
different group.
Indeed, two different groups working on two different product lines.
That's why I wasn't aware of Jiri's work. This patch (ccing netdev)
was posted around June. Anyway, Stephen did a really good job merging
the two versions.
Yep, Stephen reported on the conflict and Jiri acked the way he fixed
that, we were aware of things and didn't think any further action is
needed from our side. Both the mlx4 and mlx5 are stacked driver suites
that have a core and Ethernet drivers developed trough netdev and RDMA
driver that goes through the rdma tree, it's been working like this for
almost ten years, with net-next : rdma-next conflicts happening from
time to time and being solved successfully with Stephen & CO and the
subsystem maintainers. We're happily having now also our switch drivers
joining the party, and things should be OK, as long as the maintainer
-next tree is fully subscribed to linux-next merge tests.
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
