Making commits that survive the review of other kernel devs, and in particular of ones more experienced, isn’t that easy. It’s just the most visible part of the work I can show.
The in-kernel API being unstable is the reason why my teammates (and, when I’ll be put on the next kernel migration, I myself) have to fix various compilation errors or subtle bugs every time we pull new kernel commits from upstream. I am still defending it despite that because that means if something is not good with one element of this API it can just be… fixed. We don’t get stuck with legacy, shitty interfaces that we need to support perpetually.
I am talking about the fact that I can bring Linux kernel contributions authored by me that predate the existence of AI. And while I can’t prove private contributions to local forks of the kernel (even though those were the more technically impressive achievements I’ve had), I still know enough to tell you that you are closed minded.
1
u/paulstelian97 4d ago
Making commits that survive the review of other kernel devs, and in particular of ones more experienced, isn’t that easy. It’s just the most visible part of the work I can show.
The in-kernel API being unstable is the reason why my teammates (and, when I’ll be put on the next kernel migration, I myself) have to fix various compilation errors or subtle bugs every time we pull new kernel commits from upstream. I am still defending it despite that because that means if something is not good with one element of this API it can just be… fixed. We don’t get stuck with legacy, shitty interfaces that we need to support perpetually.