I always loved tweaking around with my computer—trying various Linux distros and window managers. Contributing to the Linux kernel had always been on my bucket list.
I first heard about the LFX Mentorship Program at KubeDay India, and the idea of Linux kernel bug fixing immediately caught my eye.
I applied last year but didn’t get in. Fast forward to this year, and when I received the acceptance email, I was literally yelling! It was an unforgettable moment.
My experience from last year in setting up the kernel build environment helped me finish my tasks a bit quicker this time. It felt like those earlier efforts weren't wasted.
Mentorship and Community
The program began in March 2025. The initial days involved a lot of learning—diving into videos, blogs, and experiencing a little bit of panic that I hadn't submitted any patches yet.
Office hours to the rescue! Our mentor, Shuah, taught us a lot about the kernel ecosystem, cscope, Git tips, and how to interpret syzkaller reports. This was incredibly helpful.
Being able to talk with fellow mentees and share our learnings in the discord server made a huge difference.
The greatest part of the Linux community is its vast amount of resources. You truly learn a lot from studying other people’s patches. The kernel mailing list archives (lore) became my bread and butter. Over three months, I went through countless patches from many contributors, which taught me a ton.
A shout out to Nathan Chancellor and Kuan-Wei Chiu for answering all my questions and for guidance.
Key Learnings
Over these 12 weeks, I experimented with various tools and learned many aspects of the kernel. I submitted 13 patches, experiencing both successes and rejections.
- Mindset: When my first patch was merged, I hesitated to send similar fixes because I was afraid of harsh feedback. Ironically, those same changes were later sent in by others— were accepted. This experience changed my mindset and I no longer fear making mistakes. Every patch has been a learning experience.
I once sent a patch to the wrong maintainer (thanks, Zsh autocomplete). After making a silly mistake like that, I guess there's no more room to be afraid! :)
Writing Good Patches: Reading the documentation for the subsystem you’re working on is so important. Always check how patches for that subsystem are being sent in the archives.
Avoiding Churn: Avoid sending patches that adds unnecessary noise. When working on a bug it's important to understand where a particular error is coming from and how your fix solves it, and most importantly to test thoroughly!
While my mentorship comes to an end, I still have a lot of things to do and hope to make some significant contributions!
Top comments (0)