Receiving and Submitting Patches

The Post-Submission Process: From Sending to Revising

After you've sent your patch series to the appropriate mailing list (typically using git send-email), the review process begins. This isn't like a corporate code review; it's a public, asynchronous conversation.

Let's break down what happens next.

1. The Waiting Game: Patience and Persistence

Once your patch is on the mailing list, you must be patient. Maintainers and reviewers are often volunteers with heavy workloads.

So, what if a week or two passes with complete silence? This is a common point of anxiety for new contributors.

In summary:

• Wait at least a week. During merge windows (the two weeks after a new kernel is released), wait even longer.
• If there's no response, resend the exact same patch series with [RESEND] added to the subject. This acts as a polite bump in the mailing list.
• Don't use [RESEND] if you have made any changes. That would be a new version (v2).

2. Receiving and Understanding Feedback

When feedback arrives, it will be in the form of email replies on the mailing list. The community has a very specific and effective communication style.

To participate effectively, you must follow the established etiquette.

Feedback can be more than just requested changes. You'll often see specific "tags" added by reviewers, which act as a formal record of their assessment.

Here's a quick summary of the most common tags you'll receive from others:

• Reviewed-by:: A strong endorsement. It means a developer has thoroughly reviewed your patch for technical correctness and quality and believes it is ready for inclusion.
• Acked-by:: An approval from a maintainer or domain expert who agrees with the change but may not have done a full, line-by-line review. It signifies that the patch fits within their subsystem's architecture and goals.
• Tested-by:: Confirmation that someone has applied your patch and successfully tested it in their environment. This is extremely valuable.
• Suggested-by:: Gives credit to the person who originally proposed the idea for the fix or feature.

When you receive these tags, you should add them to your commit message in the next version of your patch.

3. Responding to and Incorporating Feedback

This is where the iterative cycle truly begins. It's exceptionally rare for a patch to be accepted on the first try.

Your workflow for handling feedback should be:

1. Acknowledge and Discuss: Reply to the feedback on the mailing list (using inline replies!). Thank the reviewers for their time. Answer any questions they had and confirm you will address the requested changes in the next version. Professionalism is paramount, even if the feedback feels harsh.
2. Update Your Code: Go back to your local Git branch. Use git rebase -i to navigate to the correct commit and git commit --amend to make the necessary changes.
3. Write a Patch Changelog: For the new version of your patch (v2), you must document what changed since v1. This changelog is not part of the permanent Git history but is essential for reviewers. It goes below the --- separator in your cover letter (for a series) or the individual patch file.

Your v2 cover letter might look like this:

Subject: [PATCH v2 0/2] drivers: my-driver: Add support for new hardware

This series adds support for the new FooBar device.
Patch 1 adds the basic data structures.
Patch 2 implements the probe function.

---
Changes in v2:
- Replaced the use of kmalloc with devm_kmalloc in patch 2 as
  suggested by Reviewer A.
- Corrected a typo in a comment in patch 1.
- Added Reviewed-by: Reviewer B <reviewer.b@example.com> to patch 1.

... rest of the file ...

4. Submitting the Next Version

With your code updated and changelog written, you are ready to submit the new version.

1. Generate the New Patch Series: Use the -v<N> flag as you learned in the previous lesson. For a two-patch series, the command would be:

   git format-patch --cover-letter -v2 -2 HEAD
   

2. Add the Changelog: Open the generated 0000-cover-letter.patch file and add your changelog below the --- separator.
3. Send the New Version: Use git send-email to send the new series. Crucially, ensure you Cc: the reviewers who provided feedback. The get_maintainer.pl script helps, but you should manually add anyone who commented on the previous version to keep them in the loop.

This cycle—revise, document, resubmit—continues until the maintainer is satisfied and applies your patch to their tree.

Interview Scenario

An interviewer asks: "You've submitted a three-patch series to the LKML. A week later, you get a reply from a subsystem maintainer. They say patch 1 looks good and give you an Acked-by: tag. For patch 3, they ask you to fix a potential null-pointer dereference. Describe, in detail, your step-by-step process for submitting v2."

Conclusion

You have now completed the entire journey of a Linux kernel contribution, from identifying a change to navigating the crucial review and revision cycle. This is the heart of open-source collaboration.

Key Takeaways:

• The process is iterative: Expect feedback and multiple versions. This is a sign of a healthy, quality-focused process.
• Communication is key: Be patient, persistent, and professional. Always follow mailing list etiquette like inline replies.
• Document your changes: Use the changelog section (below ---) in new versions to help reviewers understand what you've updated.
• Give credit: Add Reviewed-by, Acked-by, and Tested-by tags you receive to your commit messages.

By understanding and practicing this workflow, you have the skills not only to contribute code but to become a respected member of the Linux kernel community. This concludes our module on the open-source contribution workflow. You now have a complete, practical framework to begin your journey as a kernel developer.