Re: [GIT PULL] bcache revert

[Jens Axboe <axboe@fb.com>]

On 08/31/2015 02:17 PM, Kent Overstreet wrote:
>>> Really, as long as you think it's ok to commit patches without CCing the mailing
>>> list _or_ the maintainer, then fuck you. I wouldn't do that to you and I don't
>>> know anyone else who would, so as long as that's your attitude about it there's
>>> really nothing to discuss.
>>
>> I already said that, yes, it should have been posted. But it's not like it
>> was unreviewed. Or a massive change, by any stretch.
>
> And then you said you'd do it again.
>
> Look, it's about extending a basic courtesy - other people I work with have no
> issue with this. Tejun still pings me and lets me know about percpu refcount
> changes even though he's taken over as maintainer of that code since almost
> after I wrote it. Similarly with most anyone else I've worked with in the kernel
> community. I've always put quite a bit of effort into making sure I don't miss
> anyone on my CC lists when I was doing work in the block layer that touched all
> kinds of code.
>
> Why not you?

Kent, can we cut down on the victim playing? I said it should have been 
posted, did I not? And usually patches like that ARE always posted, but 
this beat the series of patches that it was a pre-patch for. Hence it 
just didn't get posted, and that was a mistake, after a private 
discussion where it ended up being cherry-picked for inclusion. Even for 
a trivial patch like this. But it's not the end of the world, it's not 
like I rewrote your architecture or grand caching design.

>> And we're still not discussing the motives for why it looked like that in
>> the first place?
>
> Not terribly interested in doing that after the fact, when you've already
> bypassed me and gotten your patch in, and you're still saying you'd do it again.
> Sorry, I'm not having the discussion on those terms.

Grow up. We should revert a patch cleaning up macros with returns in 
them, but you won't really let us in on why?

Unless we can turn this into a REAL (and technical) discussion on why we 
should revert to the old code, I'm done spending time on this thread.

-- 
Jens Axboe