@llvm @corbet

Good talk, but it still framed the same old way: there are only Kernel Maintainers.

And then some help is requested, but those helpers neither have names nor roles in the project.

You need Kernel Code Reviewers, you need Kernel CVE Checkers, you need Kernel Subsystem Infra Engineers and Kernel Regression Trackers, and Kernel Doc Writers... you need the variety of roles.

Yet you say - come and help The Maintainer, while we won't even give you a name for doing that.

@llvm @corbet

Jonathan says: companies like to hire Kernel Maintainers but do not recognize the work they do. And that's a problem, yes.

But the larger problem is that companies do not hire people who are *not* Kernel Maintainers at all. Because they are invisible.

A person should be able to proudly put "I am a Kernel Build Engineer" on their cv and not feel awkward with "I am doing some stuff which I don't know how to call as I am not really a Kernel Developer.."

I wonder if @kernellogger has a talk somewhere on

"How to introduce a new role to the kernel project and start to get paid for it"

@llvm @corbet

@bookwar @llvm @corbet

Not yet, but the idea for such a talk is in my head for a while already.

But it has to wait for some day in maybe two or three years from now, as things wrt to "getting payed" are definitely not stable for me yet[1]. The title thus could become "how I failed to introduce…" in the end. 🥴

[1] unstable would be the better term right now, but I'm still optimistic that things hopefully turn to the better soon again

@kernellogger

You can start with "Challenges and roadblocks while introducing a new role" maybe?

Your work is a great example of how much value can be provided to a development project by doing something else rather than writing and merging code.

It would be a huge failure for the project to lose it.

@llvm @corbet

@bookwar @llvm That's funny, I could have sworn I talked about the need for people to do code reviews (I said that was the most important thing to take away from the talk), documentation writers (I *am* aware of documentation, after all), and so on. About how it shouldn't be the maintainers doing all of that.

I'm not really sure what else you think I should have wedged into a 20-minute slot; I'm sorry you were disappointed with it.

@corbet

> I said that was the most important thing to take away from the talk

I think that was good and worked. At least that was the main message I got from it.

Yet, I am trying to think of next steps. And I think that there is a difference between saying:

1) Help Kernel Maintainers do the code review

2) Become a Kernel Code Reviewer

Roles and status are important in this game.

And if you need people to do the work, they need to get recognized for more than just "helping".

@llvm

@bookwar @llvm The thing is, I don't think we should have "reviewers" as a separate role. That is something that developers should be doing as a matter of course. They are best placed to do that work, but just as importantly, it's one of the best ways to learn about the kernel outside of one's little corner.

@corbet

Every reviewer is a developer. Not every developer is a reviewer.

Reviewing someone else's work is an additional effort. And it needs to be additionally rewarded.

And setting up explicit roles to highlight certain types of work is one of the very few tools a FOSS project has for that.

If you can not give people salary, you can at least give them proper praise for the effort they put into the project. And then hope that they will find a way to monetize it.

@llvm

@corbet @llvm

I know some folks here tend to be skeptical of OpenStack, but I think it is a very interesting project from this perspective.

Mostly because unlike classical FOSS projects, OpenStack from the start was a corporate playground where every company has its own agenda, but needs to be forced into collaboration.

It didn't grow into this position like the kernel, but rather it was born this way.

It created *interesting* issues. it also allowed innovative approaches to solve them.

1/

@corbet @llvm

For example every company wants to pay for development of their feature, but doesn't want to review or maintain things merged by others.

To highlight the value of the review work OpenStack created Core Reviewers role instead of Core Developers. Your contribution is not measured by the lines of code you write, but by the number of reviews you did and emails you sent.

2/

@corbet @llvm

Same way the project added the mandatory CI:

if your change doesn't pass the shared CI, you don't get through until you fix it.

And yes, it is annoying to deal with CI failures, if you know that *your code* is of course flawless. But it again forces companies to invest paid employees time into the stability of the common infra, integration and regression testing. Because it blocks *their* features from landing.

3/3

I wouldn't say kernel needs to copy all that, but it is definitely interesting to see how project can shape and highlight certain parts of work by being intentional about its rules and tools.

@corbet @llvm

@bookwar @kernellogger @llvm @corbet Not a maintainer (nor much of a contributor), but I wrote something fairly recently about the perverse incentives to not do kernel code reviews: https://lore.kernel.org/ksummit/e7554530-a1a5-216f-9a17-7cf763ee6a9d@oracle.com/

IOW, I agree with you that reviews/reviewers are not properly recognized today and that's a problem.

@corbet @bookwar @llvm while I definitely think we need more review from developers in general (and in mm we do get it quite regularly actually) I, as a reviewer in MAINTAINERS, find it a useful stepping stone towards possible maintainership in the future and is useful in helping me feel a part of the community (+ encouraging more review).

I do reviews (when I have time, grr book) in various bits of mm though, however often it ends up being things I have worked on in the past and have some stake in/want to help people out.

Though I have put my money where my mouth is quite a bit when I've had time and have given many reviews where I thought it'd be helpful as I feel it's both useful to contribute back and helpful at learning more bits of mm.

But perhaps in any case the 'reviewer' title is poorly named, 'assistant maintainer' or something between developer and maintainer would be helpful.

I am sure @hyeyoo, a young and upcoming talent in the kernel who is a reviewer for SLAB, finds it useful and for these younger talented people it's a powerful motivator I think.

Another aspect to this is, even if I were to somehow blag my way into maintainership at some point in the medium term (for instance after hearing about how joyous it is ;), I just couldn't do it due to my work obligations. So having in-betweeny stages is helpful on that basis too (I am sure there are FAR more talented people than me who find themselves in similar situations).

Also, obviously, I am very much with you on the documentation front.

Also, FANTASTIC talk, thanks very much for continuing to put emphasis on these important topics.

@bookwar @llvm @corbet uh no please, nobody needs Kernel CVE Checkers :) but maybe depends on what exactly you mean by it. My understanding is: people who retroactively fill dubious CVEs for random old fixes.

@vbabka

I rather meant the opposite: people who would triage the filed CVEs, link them to existing bugs and track whether these bugs were closed, backported to all stable branches, etc.

In the end, the role definitions may vary and should depend on the tasks you want to be done.

The main point is that all work should have a name and give you a recognition within the project.

@llvm @corbet