DOC: Fix typos in CONTRIBUTING

Fixes typos introduced in 09e0d7422e
as well as anything found by `spell`.
This commit is contained in:
Tim Duesterhus 2019-06-15 19:47:29 +02:00 committed by Willy Tarreau
parent a8ee4b199f
commit 2847f14c94

View File

@ -41,7 +41,7 @@ their spare time. The ideal model for developers is to spend their time :
It turns out that on a project like HAProxy, like many other similarly complex It turns out that on a project like HAProxy, like many other similarly complex
projects, the time spent is exactly the opposite: projects, the time spent is exactly the opposite:
1) reviewing other peopel's code 1) reviewing other people's code
2) doing maintenance backports 2) doing maintenance backports
3) fixing bugs 3) fixing bugs
4) developing new features 4) developing new features
@ -130,7 +130,7 @@ on your work in progress. Also, don't waste your time with the doc when
submitting patches for review, only add the doc with the patch you consider submitting patches for review, only add the doc with the patch you consider
ready to merge (unless you need some help on the doc itself, of course). ready to merge (unless you need some help on the doc itself, of course).
Another important point concerns code portability. Haproxy requires gcc as the Another important point concerns code portability. HAProxy requires gcc as the
C compiler, and may or may not work with other compilers. However it's known to C compiler, and may or may not work with other compilers. However it's known to
build using gcc 2.95 or any later version. As such, it is important to keep in build using gcc 2.95 or any later version. As such, it is important to keep in
mind that certain facilities offered by recent versions must not be used in the mind that certain facilities offered by recent versions must not be used in the
@ -190,7 +190,7 @@ work's author.
Rules: the 12 laws of patch contribution Rules: the 12 laws of patch contribution
----------------------------------------- ----------------------------------------
People contributing patches must apply the following rules. That may sound heavy People contributing patches must apply the following rules. That may sound heavy
at the beginning but it's common sense more than anything else and contributors at the beginning but it's common sense more than anything else and contributors
@ -263,7 +263,7 @@ do not think about them anymore after a few patches.
necessarily belong to a dirty project. Be careful to the way the text you necessarily belong to a dirty project. Be careful to the way the text you
add is presented and indented. Be very careful about typos, usual mistakes add is presented and indented. Be very careful about typos, usual mistakes
such as double consonants when only one is needed or "it's" instead of such as double consonants when only one is needed or "it's" instead of
"its", don't mix US english and UK english in the same paragraph, etc. "its", don't mix US English and UK English in the same paragraph, etc.
When in doubt, check in a dictionary. Fixes for existing typos in the doc When in doubt, check in a dictionary. Fixes for existing typos in the doc
are always welcome and chasing them is a good way to become familiar with are always welcome and chasing them is a good way to become familiar with
the project and to get other participants' respect and consideration. the project and to get other participants' respect and consideration.
@ -737,7 +737,8 @@ The area the patch applies to is quite important, because some areas are known
to be similar in older versions, suggesting a backport might be desirable, and to be similar in older versions, suggesting a backport might be desirable, and
conversely, some areas are known to be specific to one version. The area is a conversely, some areas are known to be specific to one version. The area is a
single-word lowercase name the contributor find clear enough to describe what single-word lowercase name the contributor find clear enough to describe what
part is being touched. The following tags are suggested but not limitative : part is being touched. The following list of tags is suggested but not
exhaustive:
- examples example files. Be careful, sometimes these files are packaged. - examples example files. Be careful, sometimes these files are packaged.
@ -913,7 +914,7 @@ What to do if your patch is ignored
All patches merged are acknowledged by the maintainer who picked it. If you All patches merged are acknowledged by the maintainer who picked it. If you
didn't get an acknowledgement, check the mailing list archives to see if your didn't get an acknowledgement, check the mailing list archives to see if your
mail was propely delivered there and possibly if anyone responded and you did mail was properly delivered there and possibly if anyone responded and you did
not get their response (please look at http://haproxy.org/ for the mailing list not get their response (please look at http://haproxy.org/ for the mailing list
archive's address). archive's address).
@ -921,25 +922,25 @@ If you see that your mail is there but nobody responded, please recheck :
- was the subject clearly indicating that it was a patch and/or that you were - was the subject clearly indicating that it was a patch and/or that you were
seeking some review? seeking some review?
- was your e-mail mangled by your mail agent ? If so it's possible that - was your email mangled by your mail agent? If so it's possible that
nobody had the willingness yet to mention it. nobody had the willingness yet to mention it.
- was your e-mail sent as HTML ? If so it definitely ended in spam boxes - was your email sent as HTML? If so it definitely ended in spam boxes
regardless of the archives regardless of the archives.
- did the patch violate some of the principles explained in this document? - did the patch violate some of the principles explained in this document?
If none of these cases matches, it might simply be that everyone was busy when If none of these cases matches, it might simply be that everyone was busy when
your patch was sent and that it was overlooked. In this case it's fine to your patch was sent and that it was overlooked. In this case it's fine to
either resubmit it or respond to your own e-mail asking if anything's wrong either resubmit it or respond to your own email asking if anything's wrong
about it. In general don't expect a response after one week of silence, just about it. In general don't expect a response after one week of silence, just
because your e-mail will not appear in anyone else's current window. So after because your email will not appear in anyone else's current window. So after
one week it's time to resubmit. one week it's time to resubmit.
Among the mistakes that tend to make reviewers not respond are those who send Among the mistakes that tend to make reviewers not respond are those who send
multiple versions of a patch in a row. It's natural for others then to wait for multiple versions of a patch in a row. It's natural for others then to wait for
the series to stabilize. And once it doesn't move anymore everyone forgot about the series to stabilize. And once it doesn't move anymore everyone forgot about
it. As a rule of thumb, if you have to update your original e-mail more than it. As a rule of thumb, if you have to update your original email more than
twice, first double-check that your series is really ready for submission, and twice, first double-check that your series is really ready for submission, and
second, start a new thread and stop responding to the previous one. In this second, start a new thread and stop responding to the previous one. In this
case it is well appreciated to mention a version of your patch set in the case it is well appreciated to mention a version of your patch set in the