lkml.org 
[lkml]   [2015]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [GIT PULL] bcache revert
From
Date
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



\
 
 \ /
  Last update: 2015-08-31 22:41    [W:0.043 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site