All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@fb.com>
To: Kent Overstreet <kent.overstreet@gmail.com>
Cc: <torvalds@linux-foundation.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] bcache revert
Date: Mon, 31 Aug 2015 14:47:45 -0600	[thread overview]
Message-ID: <55E4BD71.9020109@fb.com> (raw)
In-Reply-To: <20150831204231.GA17467@kmo-pixel>

On 08/31/2015 02:42 PM, Kent Overstreet wrote:
> On Mon, Aug 31, 2015 at 02:25:25PM -0600, Jens Axboe wrote:
>> 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.
>
> You're backpedalling and trying not to admit it. Look, would you do it again or
> not? Because yes of course I'm going to call you out on it if you think this is
> an acceptable thing to do, which is certainly what you started off saying.

Kent, this is starting to get into playground territory. Should it have 
been posted/cc'ed to you? Yes. Do I think it's a big deal that it 
wasn't, given the nature of the patch? No. Is/was the patch the right 
thing to do? Yes.

>> 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.
>
> Because what's the point of having a technical discussion if you're checking in
> code behind my back, and you refuse to say you won't do so again in the future?

Get to the point.

> And calling it "just a cleanup" is disingenuous. You're making a real semantic
> change to the code, which never mind the pros and cons of the patch itself,
> means I have now have to rebase ~1000 patches on top of it and it will _silently
> break, in a nasty way_ any patches that make use of closures - you just made
> a lot of work for me, especially if I want to keep my tree bisectable.
>
> You remember how patches are supposed to go through the maintainer? This is part
> of the reason. Are you starting to see why I'm in such a bad mood?

You still forgot the part where you explained the very good reasons for 
the why the code looked like that.

-- 
Jens Axboe


  reply	other threads:[~2015-08-31 20:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-31 19:00 [GIT PULL] bcache revert Kent Overstreet
2015-08-31 19:14 ` Jens Axboe
2015-08-31 19:29   ` Kent Overstreet
2015-08-31 19:42     ` Jens Axboe
2015-08-31 19:53       ` Kent Overstreet
2015-08-31 20:06         ` Jens Axboe
2015-08-31 20:17           ` Kent Overstreet
2015-08-31 20:25             ` Jens Axboe
2015-08-31 20:42               ` Kent Overstreet
2015-08-31 20:47                 ` Jens Axboe [this message]
2015-08-31 20:57                   ` Kent Overstreet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E4BD71.9020109@fb.com \
    --to=axboe@fb.com \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.