[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251109141452.7097-1-swarajgaikwad1925@gmail.com>
Date: Sun, 9 Nov 2025 14:14:50 +0000
From: Swaraj Gaikwad <swarajgaikwad1925@...il.com>
To: dev.jain@....com
Cc: akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org,
swarajgaikwad1925@...il.com
Subject: Re: Guidance on contributing to MM subsystem
Hi Dev,
Thank you so much for your reply and for sharing your experience.
I do have some basic understanding of how parts of the MM subsystem work,
but I’m still struggling with how to find meaningful issues or tasks to work
on. For example, I’ve been trying to explore various parts of the code and
read through documentation to get a better grasp of how things fit together.
In other open-source projects, like on GitHub, there’s usually an “Issues”
section where contributors can easily find bugs or tasks to work on. In the
kernel, should I mainly focus on exploring TODOs, adding selftests, or
improving documentation (especially for new or less-documented parts)? I
also believe branches like mm-unstable and mm-new might have ongoing issues
or regressions, but how do developers usually find or detect them? Would
simply building these branches expose such problems through compiler errors,
or should I try building with different configurations (for example, using
defconfig and other configs) to uncover potential issues?
Even though I’m beginning to understand how different parts of the subsystem
interact, I’m not sure how developers usually identify new bugs or feature
ideas to work on. Once I understand the code flow better, how can I
effectively find such issues or areas where help is actually needed?
Thanks again for your time and guidance!
Best regards,
Swaraj Gaikwad
Powered by blists - more mailing lists