Re: [GIT PULL] bcache revert

[Kent Overstreet <kent.overstreet@gmail.com>]

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.

> 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?

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?