I'll admit the pull request was a little marginal for patches that would be landing in -rc4, which is roughly halfway through the development cycle. That being said, all of the patches got independent review (none of them were authored by me, and I reviewed them all before accepting them). I also ran the tests through a very extensive regression test suite. (<a href="https://thunk.org/gce-xfstests" rel="nofollow">https://thunk.org/gce-xfstests</a>). So even though many of the commits landed very recently, in my experience testing catches many more problems than end user testing in linux-next, because not that many people run linux-next.<p>Granted, I certainly wouldn't have sent this pull request any later. After rc4 the only thing I would send are regression fixes, and at most one commit in this pull request could be considered a regression fixes. The last commit listed in the short log "make xattr inode reads faster" optimizes a new feature (large xattr support) that only landed in this merge window. So it's not going to have many users, and I figured it was safe.<p>Cleanups have always been in the grey area. I certainly wouldn't have any hesitation sending these cleanups a week or two earlier. None of them were terribly large by themselves, although as a whole it's a somewhat large merge request for at this point in the cycle:<p>13 files changed, 290 insertions(+), 196 deletions(-)<p>If I screwed up, and missed a bug in my code review, and it wasn't picked up in the testing, ultimately I'm the one that's going to be held accountable. Which presumably means that Linus isn't going to be trust me in the future when I send in another marginal pull request.<p>In the past, when I was ultra-conservative and wouldn't send any of these fixes until the merge window, Greg K-H would sometimes grump at me because it would delay the fixes getting to stable kernel, and it would also contribute towards making his workload more "lumpy". What I would have done after -rc4 (and perhaps what I should have done for -rc4) is to only push those fixes that were cc'ed to stable@vger.kernel.org or were specifically regression fixes.<p>Bottom line: I did realize that what I was sending to Linus was pushing the boundaries a bit. And Linus was making sure that I knew that.
This seems a prime example of Linus being a pretty awesome maintainer. Blunt, but really just honest on messaging.<p>Or was I supposed to read this differently?
Every post I see on HM about Linus is about how cool it is that LT is an asshole.<p>What's with the skewed asshole-bias? Same people will bitch about "asshole people" on there own teams that are tough on PRs.
It always cracks me up how Torvald's "necessary, blunt honesty" is so frequently more verbose than a neutral, not-rude answer would have been.