Documentation: update stable review cycle documentation
In recent times, the review cycle for stable releases have been changed. In particular, there is release candidate phase between ACKing patches and new stable release. Also, in case of failed submissions (fail to apply to stable tree), manual backport (Option 3) have to be submitted instead. Update the release cycle documentation on stable-kernel-rules.rst to reflect the above. Cc: Sasha Levin <sashal@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-kernel@vger.kernel.org Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20220314113329.485372-4-bagasdotme@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Родитель
901581389e
Коммит
88d99e8701
|
@ -83,8 +83,8 @@ it to be applied to.
|
||||||
:ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed
|
:ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed
|
||||||
worthy at the time it is applied to a public git tree (for instance, because
|
worthy at the time it is applied to a public git tree (for instance, because
|
||||||
it deserves more regression testing first). :ref:`option_3` is especially
|
it deserves more regression testing first). :ref:`option_3` is especially
|
||||||
useful if the patch needs some special handling to apply to an older kernel
|
useful if the original upstream patch needs to be backported (for example
|
||||||
(e.g., if API's have changed in the meantime).
|
the backport needs some special handling due to e.g. API changes).
|
||||||
|
|
||||||
Note that for :ref:`option_3`, if the patch deviates from the original
|
Note that for :ref:`option_3`, if the patch deviates from the original
|
||||||
upstream patch (for example because it had to be backported) this must be very
|
upstream patch (for example because it had to be backported) this must be very
|
||||||
|
@ -153,8 +153,17 @@ Review cycle
|
||||||
- If the patch is rejected by a member of the committee, or linux-kernel
|
- If the patch is rejected by a member of the committee, or linux-kernel
|
||||||
members object to the patch, bringing up issues that the maintainers and
|
members object to the patch, bringing up issues that the maintainers and
|
||||||
members did not realize, the patch will be dropped from the queue.
|
members did not realize, the patch will be dropped from the queue.
|
||||||
- At the end of the review cycle, the ACKed patches will be added to the
|
- The ACKed patches will be posted again as part of release candidate (-rc)
|
||||||
latest -stable release, and a new -stable release will happen.
|
to be tested by developers and testers.
|
||||||
|
- Usually only one -rc release is made, however if there are any outstanding
|
||||||
|
issues, some patches may be modified or dropped or additional patches may
|
||||||
|
be queued. Additional -rc releases are then released and tested until no
|
||||||
|
issues are found.
|
||||||
|
- Responding to the -rc releases can be done on the mailing list by sending
|
||||||
|
a "Tested-by:" email with any testing information desired. The "Tested-by:"
|
||||||
|
tags will be collected and added to the release commit.
|
||||||
|
- At the end of the review cycle, the new -stable release will be released
|
||||||
|
containing all the queued and tested patches.
|
||||||
- Security patches will be accepted into the -stable tree directly from the
|
- Security patches will be accepted into the -stable tree directly from the
|
||||||
security kernel team, and not go through the normal review cycle.
|
security kernel team, and not go through the normal review cycle.
|
||||||
Contact the kernel security team for more details on this procedure.
|
Contact the kernel security team for more details on this procedure.
|
||||||
|
|
Загрузка…
Ссылка в новой задаче