Nothing particularly odd stands out on the technical side in the kernel updates for last week - rc4 looks fairly average in size for this stage in the release cycle, and all the other statistics look pretty normal too.
We've got roughly two thirds driver fixes (gpu and networking look to be the bulk of it, but there's smaller changes all over in various driver subsystems), with the rest being the usual mix: core networking, perf tooling updates, arch updates, Documentation, some filesystem, vm and minor core kernel fixes.
So it's all fairly small and normal for this stage. As usual, I'm appending the shortlog at the bottom for people who want to get an overview of the details without actually having to go dig in the git tree.
The one change that stands out and merits mention is the code of conduct addition...
[ And here comes the other, much longer, part... ]
Which brings me to the *NOT* normal part of the last week: the discussions (both in public mainly on the kernel summit discussion lists and then a lot in various private communications) about maintainership and the kernel community. Some of that discussion came about because of me screwing up my scheduling for the maintainer summit where these things are supposed to be discussed.
And don't get me wrong. It's not like that discussion itself is in any way new to this week - we've been discussing maintainership and community for years. We've had lots of discussions both in private and on mailing lists. We have regular talks at conferences - again, both the "public speaking" kind and the "private hallway track" kind.
No, what was new last week is really my reaction to it, and me being perhaps introspective (you be the judge).
There were two parts to that.
One was simply my own reaction to having screwed up my scheduling of the maintainership summit: yes, I was somewhat embarrassed about having screwed up my calendar, but honestly, I was mostly hopeful that I wouldn't have to go to the kernel summit that I have gone to every year for just about the last two decades.
Yes, we got it rescheduled, and no, my "maybe you can just do it without me there" got overruled. But that whole situation then started a whole different kind of discussion. And kind of incidentally to that one, the second part was that I realized that I had 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't actually funny or a good sign that I was hoping to just skip the yearly kernel summit entirely, and on the other hand realizing that I really had been ignoring some fairly deep-seated feelings in the community.
It's one thing when you can ignore these issues. Usually it’s just something I didn't want to deal with.
This is my reality. I am not an emotionally empathetic kind of person and that probably doesn't come as a big surprise to anybody. Least of all me. The fact that I then misread people and don't realize (for years) how badly I've judged a situation and contributed to an unprofessional environment is not good.
This week people in our community confronted me about my lifetime of not understanding emotions. My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it 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 somewhat painful personal admission that hey, I need to change some of my behavior, and I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely.
I am going to take time off and get some assistance on how to understand people’s emotions and respond appropriately.
Put another way: When asked at conferences, I occasionally talk about how the pain-points in kernel development have generally not been about the _technical_ issues, but about the inflection points where development flow and behavior changed.
These pain points have been about managing the flow of patches, and often been associated with big tooling changes - moving from making releases with "patches and tar-balls" (and the _very_ painful discussions about how "Linus doesn't scale" back 15+ years ago) to using BitKeeper, and then to having to write git in order to get past the point of that no longer working for us.
We haven't had that kind of pain-point in about a decade. But this week 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've talked to Greg to ask him if he'd mind finishing up 4.19 for me, so that 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 maintaining Linux. Quite the reverse. I very much *do* want to continue to do this 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 while because I needed to write a little tool called "git". I need to take a break to get help on how to behave differently and fix some issues in my tooling and workflow.
And yes, some of it might be "just" tooling. Maybe I can get an email filter in place so at when I send email with curse-words, they just won't go out. Because hey, I'm a big believer in tools, and at least _some_ problems going forward might be improved with simple automation.
I know when I really look “myself in the mirror” it will be clear it's not the only change that has to happen, but hey... You can send me suggestions in email.
I look forward to seeing you at the Maintainer Summit.