On Wed, Sep 9, 2015 at 5:03 AM, Doug Ledford <[email protected]> wrote: > > Me telling Matan to Cc: netdev on patches related to their subsystem: > http://marc.info/?l=linux-rdma&m=143398479529819&w=4 > > Above was v5 of the patchset. Both the v6 and v7 of the patchset had > netdev Cc:ed on the cover letter and at least the first three patches.
Ok, good. That's the kind of information I was missing. > Here's the v7 cover and the first three patches in the netdev archives: > http://marc.info/?l=linux-netdev&m=143827052913936&w=4 .. and this is the one I will effectively have to revert because of the conflict. > Here Jason Gunthorpe is asking me if I was going to take netdev stuff > without an ack from netdev in the netdev archives: > http://marc.info/?l=linux-netdev&m=143836033706501&w=4 > > And here is my response to Jason, again, in the netdev archives: > http://marc.info/?l=linux-netdev&m=143836450808174&w=4 Good. So this was all done right, it just wasn't visible in the commit history. > See above. This was done. Ok. I've merged it in my tree now, it's just waiting for the usual compile-test. Note that a correct merge (which looking at it, Stephen didn't actually do after all) also involves getting rid of the "struct netdev_changeupper_info" type that _isn't_ actually getting filled at all, and converting your one user of it in drivers/infiniband/core/roce_gid_mgmt.c to what the networking layer actually does. > I see perfectly well Linus. I am not new to engineering. You have > stated several times that I'm missing the point, or do I see your point, > please understand mine: I *did* the things you are assuming I didn't do. Yes, I see them, thanks for the links. It would have helped if the commit logs had had a record of this somehow (ie a "Cc: netdev" etc so that I could tell during the merge that this was actually something the networking people knew about). That would have avoided a lot of my angst. Sorry, Linus -- 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
