Confirmed users
978
edits
User:Hsinyi/Gecko engineering: Difference between revisions
Jump to navigation
Jump to search
→Creating a patch & testing: patch scope & size
(→Initial communication between requesters & reviewers: commit messages) |
(→Creating a patch & testing: patch scope & size) |
||
| Line 96: | Line 96: | ||
*Reviewers should feel comfortable to reject a review request if the commit message isn’t well-written or doesn’t provide useful information. | *Reviewers should feel comfortable to reject a review request if the commit message isn’t well-written or doesn’t provide useful information. | ||
*[[https://groups.google.com/g/mozilla.dev.platform/c/qERnoJniCds/m/6DLNfrGhBQAJ Open question]] People have various preferences on the length of commit messages … We need more discussions and a much better style guide, explaining what makes a good commit message and what makes a good and descriptive bug, with a number of (good and bad) examples. | *[[https://groups.google.com/g/mozilla.dev.platform/c/qERnoJniCds/m/6DLNfrGhBQAJ Open question]] People have various preferences on the length of commit messages … We need more discussions and a much better style guide, explaining what makes a good commit message and what makes a good and descriptive bug, with a number of (good and bad) examples. | ||
===== Patch scope & size ===== | |||
It’s arguable if the size of a patch matters much and optimizing for “small changes v.s. big diffs” is hard. But a good principle to keep is: '''seek to understand''' (understand the code, implement the change), and '''seek to be understood''' (present the change in an understandable form). Normally, smaller is better. | |||
An example for arranging patches in sequence to help reviewers: https://bugzilla.mozilla.org/show_bug.cgi?id=1615581 | |||
Ensure to always stick with *the* real problem you want to fix. Be conscious about '''not''' adding unrelated fixes into that patch, even if they are super tiny. | |||
== Release health and product quality == | == Release health and product quality == | ||
== Roadmap and status communication == | == Roadmap and status communication == | ||