![]() ![]() See Development policy#Documentation policy for more information. If a feature in your patch is going to be visible to end users or administrators, make sure to update or create related documentation. See Gerrit/Commit message guidelines for more.Īlso, make sure to proofread and use proper spelling and punctuation in your commit message. Write a meaningful commit message Ĭommit message should describe what and why. However, if your commits are going to be touching the same files repeatedly, bundle them up into one large commit ( using either -amend or squashing after the fact). ![]() If your commits are going to be touching separate files and there's not a lot of dependency between them, it's probably best to keep them as smaller discrete commits.įurthermore, make sure to not include unnecessary changes in your patch (e.g. The more files there are to review in your patch, the more time and effort a review will take and the more likely several reviews or a larger number of review iterations will be needed. Small, independent, complete patches are more likely to be accepted. If you know that your patch needs more work, explicitly say so in Gerrit by reviewing it as "-2" or adding a "" (work in progress) prefix to the commit message. ![]() If you have not tested your patch for some reason, explicitly say so in a comment in Gerrit.Ĭonsider going through the Pre-commit checklist.Īvoid providing incomplete fixes or introducing new bugs. Test your changes in your development environment to make sure there are no compilation errors or test failures. This will save you time and potential disappointment. If your proposed code changes do not fix a bug but introduces a new feature instead, speak first to the maintainers to make sure that your idea is in the project scope and that your proposed technical approach is the optimal solution. Your patch Check beforehand if it is in scope ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |