![]() However, if your patch wasn't merged, we've all been there so don't worry. Now you need to learn more about the kernel's internals, the more you learn, the more you'll be able to submit meaningful patches! That was a very long journey, wasn't it? If your patch was successfully merged, congratulations! It's an important step to get your first patch merged, but it won't make you a ‘rockstar’ developer (sorry). For a big patch series, wait a bit longer. After a week, ensure you've followed all the rules of the kernel's communication and send the patch again or (gently) ping the maintainer. Maintainers are busy peoples so if you do not receive any replies or feedback for a few days, no rush. It’s more convenient to use Mutt than other email clients, especially as it’s now properly configured to send mails to the Linux mailing-lists. It’s in this final step that Mutt will be useful. It's important that they see you as 'the trusted maintainer of your own code'. If a reviewer or maintainer asks for a modification: see how it fits relative to the entire kernel, ask for clarifications and make sure you understand what they mean. If someone does not understand what you've done, explain it. Now all that remains is to wait for answers / remarks / comments on your code. So, you can check your email's content, who it will be sent to, the subject etc. This will go through all the email-sending process without really sending it. Last advice: before sending your email, use Git's -dry-run switch. This is a nice way to find people who could help you understand what's right / wrong in your patch submission process. This mailing list is full of people who want to start contributing to the Linux kernel with some small fixes. If your changes are related to a spelling mistake or a warning fix: add to your mail's cc field. It's a very convenient way to find everyone who's concerned by your changes! Here we want to use the get_ script in order to list all the maintainers related to the lines which you've changed in your patch. cc-cmd is a command that's used by Git to fill the cc field of your email. It's useful to add yourself on copy because if you subscribe to a lot of mailing list, this is a clever way to filter which emails are aimed to you (as you're on copy) and which are aimed at everyone (they're aimed to the mailing list and not directly you). cc is an address you want to add as copy. The last argument to this command (/tmp/) is the path to your email's body: your patch file. What does all this mean? First, git send-email is a Git command to send. Now, send the patch! You could use Mutt here but using Mutt to send patches is not a simple process and since we configured git send-email command. Also, if this is a modified version of a previous patch, you can append -vX where X is your patch version (if you do not understand what this means, just assume you're not at this step yet). If you look at the generated patch, you'll find a subject, from field with your name (your Git credentials) and a date field. This command will create a patch from the latest Git commit and will write it to a file inside /tmp change this output folder so it appears where you want it to. The best tool for this is obviously Git as it will create a nice patch, which will appear in an email format, so all you have to do is send it! Also, if checkpatch issues a warning for a line you haven't changed.fix it anyway! It seems a bit hard at first but you'll soon get used to it! Create the patchįirst, we'll ensure our patch follows Linux's coding style by testing our latest commit's changes with checkpatch:Īny warning introduced by your work has to be fixed before submission. As the maintainers receive a huge amount of emails (8.5 changes per hour on average for the kernel in 2017 that means 8.5 changes, each hour of the day, each day of the year) a set of rules has been defined to ensure efficient communication. ![]() ![]() This blog will be slightly shorter than the previous ones, but it's the most important one )Īlthough patch submission is not a big step to take, it's not the easiest one. We can be proud of ourselves! But let’s not forget that to make all our work worthwhile, we need to submit our changes to the Linux maintainers! We’ve successfully configured our tools, cloned the proper Linux repository, found something to work on and committed these changes. Here we are at the end of our long journey.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |