openstack/swift
Code Issues Proposed changes

Fix minor typos in review guidelines

Browse Source 
Change-Id: I3acb3daeacb784c4038bf54d4103fab66c52f41a
This commit is contained in:
Brian Cline 2016-04-29 04:01:39 -05:00
parent 9734998569
commit a67d91987d
1 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
REVIEW_GUIDELINES.rst
View File

@ -124,7 +124,7 @@ comment that says:
If the author (or another reviewer) agrees - it's possible the change will get If the author (or another reviewer) agrees - it's possible the change will get
updated to include that improvement before it is merged; or it may happen in a updated to include that improvement before it is merged; or it may happen in a
follow up. follow-up change.
However, remember that style is non-material - it is useful to provide (via However, remember that style is non-material - it is useful to provide (via
diff) suggestions to improve maintainability as part of your review - but if diff) suggestions to improve maintainability as part of your review - but if
@ -148,7 +148,7 @@ would be used - you may have to ask for more details before you can
successfully review it. successfully review it.
Commit messages need to have a high consistent quality. While many Commit messages need to have a high consistent quality. While many
things under source control can be fixed and improved in a follow up things under source control can be fixed and improved in a follow-up
change - commit messages are forever. Luckily it's easy to fix minor change - commit messages are forever. Luckily it's easy to fix minor
mistakes using the in-line edit feature in Gerrit! If you can avoid mistakes using the in-line edit feature in Gerrit! If you can avoid
ever having to *ask* someone to change a commit message you will find ever having to *ask* someone to change a commit message you will find
@ -179,7 +179,7 @@ If it does not - you should write some!
... and offer them to the patch author as a diff indicating to them that ... and offer them to the patch author as a diff indicating to them that
"something" like these tests I'm providing as an example will *need* to be "something" like these tests I'm providing as an example will *need* to be
included in this change before it is suitable to merge. Bonus points if you included in this change before it is suitable to merge. Bonus points if you
include suggestions for the author as to how they might improve or expanded on include suggestions for the author as to how they might improve or expand upon
the tests stubs you provide. the tests stubs you provide.
Be *very* careful about asking an author to add a test for a "small change" Be *very* careful about asking an author to add a test for a "small change"
@ -206,7 +206,7 @@ change for the change log.
Always point out typos or grammar mistakes when you see them in Always point out typos or grammar mistakes when you see them in
review, but also consider that if you were able to recognize the review, but also consider that if you were able to recognize the
intent of the statement - documentation with tpyos may be easier to intent of the statement - documentation with typos may be easier to
iterate and improve on than nothing. iterate and improve on than nothing.
If a change does not have adequate documentation it may not be suitable to If a change does not have adequate documentation it may not be suitable to
@ -218,12 +218,12 @@ Every change could have better documentation.
Like with tests, a patch isn't done until it has docs. Any patch that Like with tests, a patch isn't done until it has docs. Any patch that
adds a new feature, changes behavior, updates configs, or in any other adds a new feature, changes behavior, updates configs, or in any other
way is different than previous behavior requires docs. manpages, way is different than previous behavior requires docs. manpages,
sample configs, docstrings, descriptive prose in the source tree sample configs, docstrings, descriptive prose in the source tree, etc.
Reviewers Write Code Reviewers Write Code
-------------------- --------------------
Reviews have been shown to to provide many benefits - one of which is shared Reviews have been shown to provide many benefits - one of which is shared
ownership. After providing a positive review you should understand how the ownership. After providing a positive review you should understand how the
change works. Doing this will probably require you to "play with" the change. change works. Doing this will probably require you to "play with" the change.
@ -276,7 +276,7 @@ as part of your review.
Do not say "Does this blow up if it gets called when xyz" - rather try Do not say "Does this blow up if it gets called when xyz" - rather try
and find a test that specifically covers that condition and mention it and find a test that specifically covers that condition and mention it
in the comment so others can find it more quickly. Of if you can find in the comment so others can find it more quickly. Or if you can find
no such test, add one to demonstrate the failure, and include a diff no such test, add one to demonstrate the failure, and include a diff
in a comment. Hopefully you can say "I *thought* this would blow up, in a comment. Hopefully you can say "I *thought* this would blow up,
so I wrote this test, but it seems fine." so I wrote this test, but it seems fine."
@ -308,7 +308,7 @@ high praise - you should be sure.
A negative score means that to the best of your abilities you have not A negative score means that to the best of your abilities you have not
been able to your satisfaction, to justify the value of a change been able to your satisfaction, to justify the value of a change
against the cost of it's deficiencies and risks. It is a surprisingly against the cost of its deficiencies and risks. It is a surprisingly
difficult chore to be confident about the value of unproven code or a difficult chore to be confident about the value of unproven code or a
not well understood use-case in an uncertain world, and unfortunately not well understood use-case in an uncertain world, and unfortunately
all too easy with a **thorough** review to uncover our defects, and be all too easy with a **thorough** review to uncover our defects, and be
@ -324,7 +324,7 @@ file a bug.
Every commit must be deployable to production. Every commit must be deployable to production.
Beyond that - almost any change might be merge-able depending on Beyond that - almost any change might be merge-able depending on
it's merits! Here's some tips you might be able to use to find more its merits! Here are some tips you might be able to use to find more
changes that should merge! changes that should merge!
#. Fixing bugs is HUGELY valuable - the *only* thing which has a #. Fixing bugs is HUGELY valuable - the *only* thing which has a
@ -336,7 +336,7 @@ changes that should merge!
the cost of increased complexity, lowered maintainability, risk the cost of increased complexity, lowered maintainability, risk
of regression, or new defects. Try to focus on what is of regression, or new defects. Try to focus on what is
*impossible* without the feature - when you make the impossible *impossible* without the feature - when you make the impossible
possible things are better. Make things better. possible, things are better. Make things better.
#. Purely test/doc changes, complex refactoring, or mechanical #. Purely test/doc changes, complex refactoring, or mechanical
cleanups are quite nuanced because there's less concrete cleanups are quite nuanced because there's less concrete
@ -369,9 +369,9 @@ A note on Swift Core Maintainers
================================ ================================
Swift Core maintainers may provide positive reviews scores that *look* Swift Core maintainers may provide positive reviews scores that *look*
different from your reviews - a "+2" instead of a "+1" different from your reviews - a "+2" instead of a "+1".
But it's *exactly the same* as your "+1" But it's *exactly the same* as your "+1".
It means the change has been thoroughly and positively reviewed. The It means the change has been thoroughly and positively reviewed. The
only reason it's different is to help identify changes which have only reason it's different is to help identify changes which have