Different Open Source projects often have different review processes before your changes can be accepted or merged into the original codebase. However, there are also many common practices among them.
After making any changes, adding a new feature, or fixing a bug in an Open Source project, the most common approaches are:
Follow Project Coding Styles: Ensure the code you added meets the project's coding standards. Some projects have specific coding styles that must be followed before they can accept your changes or patches. This information is usually available on their website, or you can ask the community for guidance.
Rebuild and Compile the Project: Rebuild and compile the project to ensure it works without crashes or errors. This step ensures that your changes did not introduce any bugs into the codebase.
Install and Run the Project (if necessary): Depending on the project, you might need to install and run it to verify it works correctly. For example, after compiling the Linux Kernel, you must install and test it. Some projects may not require this step, so check with the project maintainers.
Run All Tests: Always run all available tests to ensure your changes don't break anything. Sometimes, a project might compile successfully, but some tests could fail. Running tests is essential. Additionally, many projects use CI/CD tools like GitHub Actions to run tests on various platforms. It's good practice to ensure your changes work across different environments.
Prepare Your Changes for Submission: The next step is to prepare your changes or patches for review. Different projects have different submission processes. Some might only require a commit message explaining your changes, while others might ask for a detailed cover letter. A cover letter provides a broader explanation of your changes, especially when you have multiple commits.
Submit for Review: Submit your changes to the maintainer or the public community for review, suggestions, and merging. Different projects use different platforms for code review. For example, systemd uses GitHub for reviews, while projects like Git or the Linux Kernel use public mailing lists. Always check the project's community guidelines for submission requirements.
Follow Up and Iterate: After submitting your changes, follow up on feedback. Answer community questions and be prepared to make revisions. Your changes might not be accepted initially, so iterate based on feedback. Sometimes, you need to explain certain parts of your code. Remember, Open Source is about collaboration, feedback, and iteration. Understand that your changes might not be accepted, not because they are bad, but perhaps because they don't meet certain requirements. It is helpful to discuss your proposed changes with the community before implementing them. Someone else might already be working on a similar feature.
Handling Iterations: When making revisions, different projects have different preferences. Some maintainers prefer you to rebase new changes into the previous commit, while others prefer not to. For example, the Git project prefers new patches to be sent as a new version, clearly stating the differences from the previous version. Always follow the project's guidelines for submitting updates.
In Open Source, your changes and patches are your responsibility. Stay engaged, follow through, and embrace feedback and collaboration.
Voila, congratulations your patches are accepted. While this is a good step in most OpenSource projects, you should always check with the project community to know how their patch review works.
My Outreachy Internship Progress at Git
In my project at Git, I am in the process of community review and reiterations. I have been doing different iteration of the patches I sent to the community based on the community feedback. You can check out some feedback about my patches here.
Next Line of Action:
I will keep reiterating on my patches until it is accepted and integrated into the Git codebase.
Important News
There is a new release of Git (which I am happy to say has some of patches), the Git v2.48.0 and you can read more about the new changes in a blog written by my mentor at Gitlab here.
Thank you and see you next week.