The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Linux kernel influence is earned by helping useful changes move through review—not by seeking visibility or sending patches straight to Linus. To grow into maintainership, learn a subsystem, make changes easy to assess, respond constructively to review, and build a dependable record of collaboration.
What does influence mean in the Linux kernel?
The kernel is divided into subsystems, and the work of reviewing and integrating changes is distributed among the people responsible for them. The development-process guide describes a chain of trusted subsystem trees: a maintainer generally decides whether a change belongs in the tree they oversee, and selected changes can then move through the chain toward mainline. The official development-process guide explains why sending a patch directly to Linus is normally not the right route: contributors should identify the maintainer for the code they changed.
That structure makes influence practical rather than ceremonial. A maintainer’s role reflects responsibility for a subsystem, driver, or file, and maintainers are listed in the kernel’s MAINTAINERS file. The title is not a shortcut around review; it comes with responsibility for helping evaluate and route changes.
How do I get a kernel patch accepted?
Start with a real problem and explain its impact
Before writing a patch, understand the problem it is meant to solve and who experiences it. The submission guide recommends explaining both the problem and the user-visible effect in plain English. Give reviewers enough context to assess the change rather than making them infer why it matters. The kernel patch-submission guide covers the expected approach.
#1 Best Overall
Make the change easy to evaluate
Keep the patch focused on its purpose and provide relevant technical context. Check the subsystem’s guidance before choosing a base tree or preparing a submission: conventions and integration paths can differ by area. A patch that fits the local workflow is easier for the right people to review.
Use review to improve the patch
Review is part of the work, not a verdict on a contributor’s standing. Address comments with code changes where appropriate. If you do not make a suggested change, explain the reasoning in your reply or in a changelog note so the next reviewer can see why. Clear, technically grounded responses make collaboration more effective.
Who should I send my patch to?
Identify the people and mailing lists responsible for the code you changed, then follow the subsystem’s current instructions. The kernel’s submission guide recommends consulting MAINTAINERS and using scripts/get_maintainer.pl to help identify recipients. Check whether the subsystem expects a particular base tree and review route; its local documentation is the best guide to those details.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches- Locate the files and subsystem affected by your change.
- Check the current MAINTAINERS entries and the subsystem’s documentation.
- Use
scripts/get_maintainer.plas an aid to finding relevant maintainers and lists. - Confirm the subsystem’s expected base tree and submission practices.
- Send the patch to the appropriate recipients and take part in the resulting discussion.
Why can review and integration take time?
A patch usually moves through multiple stages: design, early review on relevant lists, broader review after a subsystem maintainer accepts it into a tree, and further integration. Testing and integration can uncover issues that were not apparent in the first review. A small fix may move quickly; a large or controversial change may take much longer. The development-process guide describes this progression and notes that most maintainers also have day jobs.
Rank #3
If a patch has drawn no objections but has not been merged, keep it current and continue working through the review and merging process. Persistence here means maintaining a useful, up-to-date patch and following the project’s process—not demanding attention or acceptance.
How do I respond to Linux kernel code review?
- Read each comment carefully and determine whether it identifies a correctness, design, testing, or clarity issue.
- Revise the patch when the feedback improves it, and make the response clear about what changed.
- If you disagree or leave the code unchanged, explain why with relevant technical reasoning.
- Keep the patch aligned with the current code and the subsystem’s integration expectations while it is under review.
- Stay professional, even when discussion is difficult; maintainers and contributors share responsibility for community conduct.
What responsibilities come with maintainership?
The kernel’s interpretation of its Code of Conduct defines a maintainer as someone responsible for a subsystem, driver, or file who is listed in MAINTAINERS. It states, “First and foremost, it is a reasonable expectation to have maintainers lead by example.” The interpretation of maintainer responsibilities also makes clear that conduct responsibility is shared: a maintainer need not handle every behavior issue alone. Maintainers should help when problems arise and can seek support from the Technical Advisory Board (TAB) or other maintainers.
The Code of Conduct page reports 17 committee reports for The Linux Kernel covering April 1, 2024 through March 31, 2025. That figure describes that specific reporting period, not a current annual rate. The page also describes development-process reports that educated maintainers about their right to accept or reject patches and clarified that developers cannot demand review or acceptance. Its 2025 documentation update clarified enforcement and the TAB’s role. The Linux kernel Code of Conduct page provides the current published context.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →What does “2nd place is the first winner” mean here?
It is a useful reminder that kernel development is not organized around one person selecting every change. The development-process guide gives a historical example from its discussion of Linux 2.6.38: more than 9,500 patches were involved, while 112—about 1.3%—were selected directly by Linus. Those figures describe that historical example only; they are not a measure of today’s patch volume or acceptance patterns. The larger point is that subsystem maintainers and the trust chain carry much of the work of getting changes toward mainline.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
