Linux 4.19-rc4 released, an apology, and a maintainership note

Another week, another rc.Nothing particularly odd stands out on the technical side in thekernel updates for last week - rc4 looks fairly average in size forthis stage in the release cycle, and all the other statistics lookpretty normal too.We've got roughly two thirds driver fixes (gpu and networking look tobe the bulk of it, but there's smaller changes all over in variousdriver subsystems), with the rest being the usual mix: corenetworking, perf tooling updates, arch updates, Documentation, somefilesystem, vm and minor core kernel fixes.So it's all fairly small and normal for this stage.  As usual, I'mappending the shortlog at the bottom for people who want to get anoverview of the details without actually having to go dig in the gittree.The one change that stands out and merits mention is the code ofconduct addition...[ And here comes the other, much longer, part... ]Which brings me to the *NOT* normal part of the last week: thediscussions (both in public mainly on the kernel summit discussionlists and then a lot in various private communications) aboutmaintainership and the kernel community.  Some of that discussion cameabout because of me screwing up my scheduling for the maintainersummit where these things are supposed to be discussed.And don't get me wrong.  It's not like that discussion itself is inany way new to this week - we've been discussing maintainership andcommunity for years. We've had lots of discussions both in private andon mailing lists.  We have regular talks at conferences - again, boththe "public speaking" kind and the "private hallway track" kind.No, what was new last week is really my reaction to it, and me beingperhaps introspective (you be the judge).There were two parts to that.One was simply my own reaction to having screwed up my scheduling ofthe maintainership summit: yes, I was somewhat embarrassed abouthaving screwed up my calendar, but honestly, I was mostly hopeful thatI wouldn't have to go to the kernel summit that I have gone to everyyear for just about the last two decades.Yes, we got it rescheduled, and no, my "maybe you can just do itwithout me there" got overruled.  But that whole situation thenstarted a whole different kind of discussion.  And kind ofincidentally to that one, the second part was that I realized that Ihad completely mis-read some of the people involved.This is where the "look yourself in the mirror" moment comes in.So here we are, me finally on the one hand realizing that it wasn'tactually funny or a good sign that I was hoping to just skip theyearly kernel summit entirely, and on the other hand realizing that Ireally had been ignoring some fairly deep-seated feelings in thecommunity.It's one thing when you can ignore these issues.  Usually it’s justsomething I didn't want to deal with.This is my reality.  I am not an emotionally empathetic kind of personand that probably doesn't come as a big surprise to anybody.  Least ofall me.  The fact that I then misread people and don't realize (foryears) how badly I've judged a situation and contributed to anunprofessional environment is not good.This week people in our community confronted me about my lifetime ofnot understanding emotions.  My flippant attacks in emails have beenboth unprofessional and uncalled for.  Especially at times when I madeit personal.  In my quest for a better patch, this made sense to me.I know now this was not OK and I am truly sorry.The above is basically a long-winded way to get to the somewhatpainful personal admission that hey, I need to change some of mybehavior, and I want to apologize to the people that my personalbehavior hurt and possibly drove away from kernel developmententirely.I am going to take time off and get some assistance on how tounderstand people’s emotions and respond appropriately.Put another way: When asked at conferences, I occasionally talk abouthow the pain-points in kernel development have generally not beenabout the _technical_ issues, but about the inflection points wheredevelopment flow and behavior changed.These pain points have been about managing the flow of patches, andoften been associated with big tooling changes - moving from makingreleases with "patches and tar-balls" (and the _very_ painfuldiscussions about how "Linus doesn't scale" back 15+ years ago) tousing BitKeeper, and then to having to write git in order to get pastthe point of that no longer working for us.We haven't had that kind of pain-point in about a decade.  But thisweek felt like that kind of pain point to me.To tie this all back to the actual 4.19-rc4 release (no, really, this_is_ related!) I actually think that 4.19 is looking fairly good,things have gotten to the "calm" period of the release cycle, and I'vetalked to Greg to ask him if he'd mind finishing up 4.19 for me, sothat I can take a break, and try to at least fix my own behavior.This is not some kind of "I'm burnt out, I need to just go away"break.  I'm not feeling like I don't want to continue maintainingLinux. Quite the reverse.  I very much *do* want to continue to dothis project that I've been working on for almost three decades.This is more like the time I got out of kernel development for a whilebecause I needed to write a little tool called "git".  I need to takea break to get help on how to behave differently and fix some issuesin my tooling and workflow.And yes, some of it might be "just" tooling.  Maybe I can get an emailfilter in place so at when I send email with curse-words, they justwon't go out.  Because hey, I'm a big believer in tools, and at least_some_ problems going forward might be improved with simpleautomation.I know when I really look “myself in the mirror” it will be clear it'snot the only change that has to happen, but hey...  You can send mesuggestions in email.I look forward to seeing you at the Maintainer Summit.                Linus