process.rst: Perform minor cleanups
- Use gender-neutral language to refer to the user, consistently. - Reword a few places so that they read more naturally. - Make the long standing practice around "Twilight Time" more clear, hopefully. - Replace a reference to MAKEALL with a reference to CI testing as that's the current requirement. Cc: Claudius Heine <ch@denx.de> Cc: Martin Bonner <martingreybeard@gmail.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com>
This commit is contained in:
@@ -46,21 +46,22 @@ Twilight Time
|
|||||||
-------------
|
-------------
|
||||||
|
|
||||||
Usually patches do not get accepted as they are - the peer review that takes
|
Usually patches do not get accepted as they are - the peer review that takes
|
||||||
place will usually require changes and resubmits of the patches before they
|
place will usually require changes and resubmissions of the patches before they
|
||||||
are considered to be ripe for inclusion into mainline.
|
are considered to be ripe for inclusion into mainline.
|
||||||
|
|
||||||
Also, the review often happens not immediately after a patch was submitted,
|
Also the review often happens not immediately after a patch was submitted,
|
||||||
but only when somebody (usually the responsible custodian) finds time to do
|
but only when somebody (usually the responsible custodian) finds time to do
|
||||||
this.
|
this.
|
||||||
|
|
||||||
In the result, the final version of such patches gets submitted after the
|
The result is that the final version of such patches gets submitted after the
|
||||||
merge window has been closed.
|
merge window has been closed.
|
||||||
|
|
||||||
It is current practice in U-Boot that such patches are eligible to go into the
|
It is current practice in U-Boot that such patches are eligible to go into the
|
||||||
upcoming release.
|
upcoming release.
|
||||||
|
|
||||||
In the result, the release of the ``"-rc1"`` version does not immediately follow
|
The result is that the release of the ``"-rc1"`` version and formal closing of
|
||||||
the closing of the Merge Window.
|
the Merge Window does not preclude patches that were already posted from being
|
||||||
|
merged for the upcoming release.
|
||||||
|
|
||||||
Stabilization Period
|
Stabilization Period
|
||||||
--------------------
|
--------------------
|
||||||
@@ -75,13 +76,13 @@ Sometimes it is not clear if a patch contains a bug fix or not.
|
|||||||
For example, changes that remove dead code, unused macros etc. or
|
For example, changes that remove dead code, unused macros etc. or
|
||||||
that contain Coding Style fixes are not strict bug fixes.
|
that contain Coding Style fixes are not strict bug fixes.
|
||||||
|
|
||||||
In such situations it is up to the responsible custodian to decide if he
|
In such situations it is up to the responsible custodian to decide if they
|
||||||
applies such patches even when the Merge Window is closed.
|
apply such patches even when the Merge Window is closed.
|
||||||
|
|
||||||
Exception: at the end of the Stabilization Period only strict bug
|
Exception: at the end of the Stabilization Period only strict bug
|
||||||
fixes my be applied.
|
fixes my be applied.
|
||||||
|
|
||||||
Sometimes patches miss the the Merge Window slightly - say by few
|
Sometimes patches miss the Merge Window slightly - say by a few
|
||||||
hours or even a day. Patch acceptance is not as critical as a
|
hours or even a day. Patch acceptance is not as critical as a
|
||||||
financial transaction, or such. So if there is such a slight delay,
|
financial transaction, or such. So if there is such a slight delay,
|
||||||
the custodian is free to turn a blind eye and accept it anyway. The
|
the custodian is free to turn a blind eye and accept it anyway. The
|
||||||
@@ -110,7 +111,7 @@ Custodians
|
|||||||
----------
|
----------
|
||||||
|
|
||||||
The Custodians take responsibility for some area of the U-Boot code. The
|
The Custodians take responsibility for some area of the U-Boot code. The
|
||||||
in-tree ``MAINTAINERS`` files list who is reponsible for which areas.
|
in-tree ``MAINTAINERS`` files list who is responsible for which areas.
|
||||||
|
|
||||||
It is their responsibility to pick up patches from the mailing list
|
It is their responsibility to pick up patches from the mailing list
|
||||||
that fall into their responsibility, and to process these.
|
that fall into their responsibility, and to process these.
|
||||||
@@ -155,7 +156,7 @@ like this:
|
|||||||
|
|
||||||
#. Applies cleanly to the source tree
|
#. Applies cleanly to the source tree
|
||||||
|
|
||||||
#. passes a ``MAKEALL`` compile test without creating new warnings
|
#. Passes :doc:`ci_testing` as this checks for new warnings and other issues.
|
||||||
|
|
||||||
#. Notes:
|
#. Notes:
|
||||||
|
|
||||||
@@ -167,7 +168,7 @@ like this:
|
|||||||
|
|
||||||
#. This is well documented in :doc:`designprinciples`.
|
#. This is well documented in :doc:`designprinciples`.
|
||||||
|
|
||||||
#. The custodian decides himself how recent the code must be. It is
|
#. The custodian decides themselves how recent the code must be. It is
|
||||||
acceptable to request patches against the last officially released
|
acceptable to request patches against the last officially released
|
||||||
version of U-Boot or newer. Of course a custodian can also accept
|
version of U-Boot or newer. Of course a custodian can also accept
|
||||||
patches against older code.
|
patches against older code.
|
||||||
@@ -177,7 +178,7 @@ like this:
|
|||||||
|
|
||||||
#. The custodian decides to accept or to reject the patch.
|
#. The custodian decides to accept or to reject the patch.
|
||||||
|
|
||||||
#. If accepted, the custodian adds the patch to his public git repository and
|
#. If accepted, the custodian adds the patch to their public git repository and
|
||||||
notifies the mailing list. This note should include:
|
notifies the mailing list. This note should include:
|
||||||
|
|
||||||
* a short description of the changes
|
* a short description of the changes
|
||||||
@@ -186,15 +187,15 @@ like this:
|
|||||||
|
|
||||||
* suggested tests
|
* suggested tests
|
||||||
|
|
||||||
Although the custodian is supposed to perform his own tests
|
Although the custodian is supposed to perform their own tests
|
||||||
it is a well-known and accepted fact that he needs help from
|
it is a well-known and accepted fact that they needs help from
|
||||||
other developers who - for example - have access to the required
|
other developers who - for example - have access to the required
|
||||||
hardware or tool chains.
|
hardware or tool chains.
|
||||||
The custodian request help for tests and feedback from
|
The custodian request help for tests and feedback from
|
||||||
specific maintainers and U-Boot users.
|
specific maintainers and U-Boot users.
|
||||||
|
|
||||||
#. Once tests are passed, some agreed time limit expires, the custodian
|
#. Once tests are passed, some agreed time limit expires, the custodian
|
||||||
requests that the changes in his public git repository be merged into the
|
requests that the changes in their public git repository be merged into the
|
||||||
main tree. If necessary, the custodian may have to adapt his changes to
|
main tree. If necessary, the custodian may have to adapt their changes to
|
||||||
allow for a clean merge.
|
allow for a clean merge.
|
||||||
Todo: define a reasonable time limit. 3 weeks?
|
Todo: define a reasonable time limit. 3 weeks?
|
||||||
|
Reference in New Issue
Block a user