You may be a Linux Kernel Maintainer - and Not Know It!

### Overview In this talk, Frank Rowand of Sony discusses an often overlooked reality for kernel developers: submitting a new driver patch series that adds an entry to the MAINTAINERS file effectively makes that engineer a Linux kernel maintainer. Rowand shares a real-life incident at Sony where an engineering team successfully contributed a TV tuner ASIC driver, only to be confused months later when receiving third-party patches. The presentation explores the unexpected responsibilities that accompany kernel maintainership, outlines the pathways patches take through the community, details various levels of maintainer involvement, examines essential patch tags, and offers best practices for testing and community communication.

### Key Topics - **Accidental Maintainership**: Developers often view adding themselves to the MAINTAINERS file as routine housekeeping, unaware that it establishes them as the point of contact for future maintenance. - **Patch Ingestion Paths**: Patches can either flow directly to subsystem maintainers (bypassing the driver maintainer for inclusion into Linux-next and Linus Torvalds' tree) or route directly through the driver maintainer as a sub-maintainer. - **Maintainer Role Tiers**: Developers can choose their level of engagement: ignoring the role (strongly discouraged unless removing their name via patch), providing informal advice and Acked-by tags, performing formal code reviews with Reviewed-by tags, or becoming full sub-maintainers who manage trees and pull requests. - **Patch Tags and Etiquette**: The meaning and responsibilities behind standard tags, including Signed-off-by, Acked-by, Reviewed-by, Fixes, and Cc stable. - **Testing and Verification Standards**: Necessary due diligence before submitting or signing off on patches, including static analysis tools and compile-time warning checks.

### Technical Details - **Tags Explained**: - **Signed-off-by**: Certifies developer origin and legal authority to submit code (chain of custody) under kernel documentation guidelines; required for all commits reaching Linus's tree. - **Acked-by**: Signals to upstream maintainers that the maintainer is fine with the patch being accepted, often used across subsystem boundaries. - **Reviewed-by**: Signifies that a technical review was conducted, feedback was resolved, and the patch represents an appropriate contribution with no critical issues, based on criteria in kernel documentation. - **Fixes**: Points to the specific commit that introduced a defect, aiding backport verification and bisect testing. - **Cc: stable**: Included in commit comments to flag fixes that should be evaluated for older stable kernel trees. - **Quality and Verification Tools**: - Style checks using `checkpatch`. - Zero new compile warnings on standard builds, with extended checks via `make W=1`, `W=2`, or `W=3`. - Static analysis using tools such as `sparse` and `smatch`. - Functional verification ensuring bug reproduction/elimination, documentation parity, and kernel boot verification across architectures (often using virtual machines or board farms). - Measuring performance trade-offs, citing how critical patches like Spectre and Meltdown accepted initial performance hits to address security.

### Takeaways - **Coordinate with Subsystem Maintainers**: Maintainers must align on expectations with their upstream subsystem leads regarding how actively they will handle patches. - **Do Not Disappear Silently**: If an engineer or company cannot maintain a driver, they should submit a patch removing their name rather than letting emails go unanswered. - **Allocate Ongoing Time**: Maintainers need dedicated work time and coverage plans during vacations to avoid blocking community patch velocity. - **Community Engagement**: Monitoring subsystem mailing lists and tracking broader architectural discussions on lists like `ksummit-discuss` helps engineers remain effective maintainers.