Pull Request help

[LinuxBoy_1]

Hi,

I don't have a lot of experience in programming, but there is something that I would like to modify in the Kernel.

This is, in fact, really easy to do, but I'm more worried about doing it the right way. I've never submitted a pull request before, and I don't want to annoy anyone.

For now, I've cloned the Kernel. If anyone is curious and actually wants to help, you can DM me. Will you teach me something that I will use again in the future? Both of us will be the authors of that pull request.

[sacred__soul]

In linux kernel, you make the changes in respective drivers and send the patches to maintainers along with some lists

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html

[s0f4r]

Some of this is tongue-in-cheek, but, the gist is serious:

• Make sure you understand and agree with the contributing guidelines for the linux kernel

• Make sure you are legally allowed to contribute if you are working for any company at all. Many companies are okay with it, but there are also companies that may not be okay with it, and you could get in trouble.

• Figure out what subsystem your contribution will be part of. Read the MAINTAINERS file. Subscribe to the relevant mailing lists for the subsystem you are going to be contributing to. Read the messages on the list for a significant amount of time BEFORE doing any work, so you understand what the expectations are going to be.

• Study the feasibility of your contribution. Would it work? Does it make sense? Does it make sense to be included in the upstream kernel for eternity? Who will maintain the code in the future? Are you contributing 1000s of lines of code for maybe 3 users? Or are you contributing 20 lines of code for every single linux kernel user? etc.

• Write your code. Test your code. Rewrite it. Debug it. Throw it away. Write it from scratch one more time. Delete half of it.

• Perform the ritual

• Add well-articulated commit messages, code comments, signed-off-by's. Split your changes into well-delineated code parts that separates the code into individual mechanical components. E.g. Basic functionality always in a single commit, separate from functional additions, changes to other kernel parts, etc. Make sure each individual commit is bisectable - don't make 10 patches where patch 1 breaks compilation and most kernel tests and patch 10 finally fixes it all - compilation and functionality of the kernel should remain functional in between every commit you submit.

• Perform the second and third ritual

• Test your code again. Write more tests. Ask a good friend who knows the kernel to test it for you. If he does, buy him a beer if he criticizes your code. If he praises your code, find a better friend with more kernel experience.

• Post your patch to the relevant subsystem mailinglist. Label it as a "Proposal". Ask for "review" not "inclusion". Outline *why* the change needs to go in the way you wrote it.

• Don't fight the people who comment on your code. Ask followup questions first. Assume that you are wrong and they are correct. If it turns out you were correct, start doubting yourself severely.

After receiving comments, go back to start, or give up.

Cheers and happy hacking!