Only clear bug fixes are wanted at this point to make the next release candidate(s) as small as possible. In this case, the PR contained some cleanups.
More changes can mean more regressions. The goal is to stabilize the master branch so that v4.13 can be released.
4.13 is due for release probably this week. Linus cut -rc3 a week ago, which was small, and nothing serious have been heard. Normally only critical fixes would be merged this late which might warrant another rc, but this is Ted T'so, a wizard who has been involved in Linux since before it had networking, so his opinions have merit.
In general we always get to -rc6 to -rc8 before we do a release, with perhaps -rc7 being the most common. Since the merge window (before -rc1) is two weeks, this translates to a two month release cycle. So using a time-based release cycle paradigm, -rc3 isn't _that_ late, although as I acknowledged in another comment in this thread, it was a bit marginal.
(And by the way it's "Ts'o", but the wrong spelling is all over the Internet at this point.)
Ted Ts'o (extremely well-known developer) being warned by Linus Torvalds (extremely well-known developer) about a Git pull request that has a misleading commit message.
Linus is not an asshole and no one thinks assholes are 'cool'. This comes across as a distorted framing of the issue to fit a preconceived bias.
There are millions of lkml posts that don't get posted here, only the ones where Linus has to tick someone off or express a disagreement, usually posted with zero context or history.
If your impression of Linus is based solely on posts that make it to HN you have a lot of catching up to do.
It is not so much an "asshole bias" as a reaction against the emphasis which is placed on 'soft' skills in management: empathy, tact, drive for 'diversity' even when this means compromising on skills, etc. Linus is known to be an effective project manager who does not fit the mould of the modern 'soft' 'people manager' so any time some quotable reference appears he's cheered upon by those who don't agree with these 'modern' management styles.
People tend to view antisocial or idiosyncratic behavior in successful people as being a necessary component of their success, as it separates them from their contemporaries in the social and professional mainstream. The same can be said about many successful entrepreneurs and business people, if they're famously irascible or ill-mannered, that will be held up as a noble quality by their peers, even as it's denounced amongst their peers.
TL;DR: Linus Torvalds created Linux, and by extension a cargo cult around his personality, whereas the theoretical asshole on your team who won't take your PR is just an asshole.
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. (https://thunk.org/gce-xfstests). 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.
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.
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:
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.
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.
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.
32 comments
[ 3.6 ms ] story [ 61.7 ms ] threadMore changes can mean more regressions. The goal is to stabilize the master branch so that v4.13 can be released.
(And by the way it's "Ts'o", but the wrong spelling is all over the Internet at this point.)
Edit: correct spelling of Ts'o. :S
I think it's a reasonable 1-sentence summary.
Or was I supposed to read this differently?
I don't know, as I am an outsider, but messaging like this is as important for the crowd as it is for the directly involved.
HN has Linus talks tough and says dirty word fetish.
What's with the skewed asshole-bias? Same people will bitch about "asshole people" on there own teams that are tough on PRs.
There are millions of lkml posts that don't get posted here, only the ones where Linus has to tick someone off or express a disagreement, usually posted with zero context or history.
If your impression of Linus is based solely on posts that make it to HN you have a lot of catching up to do.
TL;DR: Linus Torvalds created Linux, and by extension a cargo cult around his personality, whereas the theoretical asshole on your team who won't take your PR is just an asshole.
Wow, how lame can you be, HN?
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.
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:
13 files changed, 290 insertions(+), 196 deletions(-)
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.
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.
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.
Geez, srsly...