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:

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 [email protected] 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.

Awesome. Sounds as if the system is working like it should. Thanks for all the ext file system work over the years.

Huge respect for both! Shows over and over again how clear communication beats political correctness every time.

It is not, however, an excuse to dismiss politically correct ways of clearly communicating.

This seems a prime example of Linus being a pretty awesome maintainer. Blunt, but really just honest on messaging.

Or was I supposed to read this differently?

If he's not convinced he shouldn't have pulled imho. Reply like this before pulling and see what they reply

That would make sense on a new maintainer. Source of these is a well trusted dev.

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.

Every post I see on HM about Linus is about how cool it is that LT is an asshole.

What's with the skewed asshole-bias? Same people will bitch about "asshole people" on there own teams that are tough on PRs.

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.

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.

Also plenty of people think assholes are cool, otherwise Dan Bilzerian would be a janitor.

Obviously assholes would find other assholes 'cool'. It's self defining.

Simply stated that every HN post about him seems praise worthy of an assholey comment.

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.

Could someone please give some context on this?

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.

Edit: correct spelling of Ts'o. :S

Arguably misleading. All of those commit lines except the very last look like bugfixes or cleanup to me.

I think it's a reasonable 1-sentence summary.

It's just some random mailing list post.

What's the problem?

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.

Some of these are large changes that are recent enough that it's impossible to vet them to Linus' standards.

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.)

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.

I don't see the s word or any cuss words as being necessary. Short and blunt is just fine.

BREAKING NEWS: Linus used word "shit" on email message.

Geez, srsly...

This is not noteworthy.

St Ignucius bless his heart