“It is important to create conditions for cooperation, which can help develop a unique product,” Russia's digital ministry said in response to 11 developers being delisted from maintaining the Linux kernel.
They haven’t been removed from the community though — just the maintainers list. Now they need someone else’s review to commit code to the kernel.
Personally, I think even maintainers should be required to have that — you can be the committer for pre-reviewed code from others, but not just be able to check anything you want in, no matter your reputation (even if you’re Linus). That way a security breach is less likely to cause havoc.
I find that difficult. Aside from code reviews, often times your job as a maintainer is:
getting a refactor or code cleanup in while everyone’s asleep
shuffling commits around between branches
fixing the CI toolchain
rolling back or repairing a broken change
unfucking the repo
fixing a security vulnerability
A required review slows all of these tasks to a crawl. I do agree that the kernel is important enough that it might be worth the trade-off.
But at the same, I do not feel like I could do my (non-kernel) maintainer job without direct commit access…
I feel your pain. I have maintainer roles for a few projects where things could be slowed down by a week or more if I didn’t have direct commit access. And I do use that access to make things run faster and smoother, and am able to step in and just get something fixed up and committed while everyone else is asleep. But. For security critical code paths, I’ve come to realize that much like Debian, sometimes slow and secure IS better, even if it doesn’t feel like it in the moment (like when you’re trying to commit and deploy a critical security patch already being exploited in the wild, and NOBODY is around to do the review, or there’s something upstream that needs to be fixed before your job can go out).
They haven’t been removed from the community though — just the maintainers list. Now they need someone else’s review to commit code to the kernel.
Personally, I think even maintainers should be required to have that — you can be the committer for pre-reviewed code from others, but not just be able to check anything you want in, no matter your reputation (even if you’re Linus). That way a security breach is less likely to cause havoc.
I find that difficult. Aside from code reviews, often times your job as a maintainer is:
A required review slows all of these tasks to a crawl. I do agree that the kernel is important enough that it might be worth the trade-off.
But at the same, I do not feel like I could do my (non-kernel) maintainer job without direct commit access…
I feel your pain. I have maintainer roles for a few projects where things could be slowed down by a week or more if I didn’t have direct commit access. And I do use that access to make things run faster and smoother, and am able to step in and just get something fixed up and committed while everyone else is asleep. But. For security critical code paths, I’ve come to realize that much like Debian, sometimes slow and secure IS better, even if it doesn’t feel like it in the moment (like when you’re trying to commit and deploy a critical security patch already being exploited in the wild, and NOBODY is around to do the review, or there’s something upstream that needs to be fixed before your job can go out).