diff options
| author | Tom Rini <[email protected]> | 2024-06-24 13:34:52 -0600 |
|---|---|---|
| committer | Tom Rini <[email protected]> | 2024-06-24 13:34:52 -0600 |
| commit | a7eada24327a40f7ef6c55c220e119839c9d4227 (patch) | |
| tree | efbea0c3cb6845fe9b5841b100c2770a60cb3f68 /doc/develop/process.rst | |
| parent | d3c610fa462a76880845920e7c535133a264448a (diff) | |
| parent | 9e9f78f7aa0124ef0e622532043acf87e84008dc (diff) | |
Merge tag 'v2024.07-rc5' into next
Prepare v2024.07-rc5
Diffstat (limited to 'doc/develop/process.rst')
| -rw-r--r-- | doc/develop/process.rst | 21 |
1 files changed, 17 insertions, 4 deletions
diff --git a/doc/develop/process.rst b/doc/develop/process.rst index 92477d05dd8..0542b3fc124 100644 --- a/doc/develop/process.rst +++ b/doc/develop/process.rst @@ -34,7 +34,7 @@ It is followed by a *Stabilization Period*. The end of a Release Cycle is marked by the release of a new U-Boot version. Merge Window ------------- +^^^^^^^^^^^^ The Merge Window is the period when new patches get submitted (and hopefully accepted) for inclusion into U-Boot mainline. This period lasts for 21 days (3 @@ -44,7 +44,7 @@ This is the only time when new code (like support for new processors or new boards, or other new features or reorganization of code) is accepted. Twilight Time -------------- +^^^^^^^^^^^^^ Usually patches do not get accepted as they are - the peer review that takes place will usually require changes and resubmissions of the patches before they @@ -65,13 +65,13 @@ the Merge Window does not preclude patches that were already posted from being merged for the upcoming release. Stabilization Period --------------------- +^^^^^^^^^^^^^^^^^^^^ During the Stabilization Period only patches containing bug fixes get applied. Corner Cases ------------- +^^^^^^^^^^^^ 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 @@ -108,6 +108,19 @@ Differences to the Linux Development Process In U-Boot, ``"-rc1"`` will only be released after all (or at least most of the) patches that were submitted during the merge window have been applied. +Resyncing of the device tree subtree +------------------------------------ + +As explained in :doc:`devicetree/control` some platforms make use of device tree +files which come from a git subtree that mirrors the Linux Kernel sources +itself. For our purposes, we only track releases and not release candidates for +merging in our tree. These merges follow the normal merge window rules. + +In the case of specific changes, such as bug fixes or new platform support, +these can be "cherry-picked" and are subject to the normal merge rules. For +example, a bug fix can come in later in the window but a full re-sync only +happens within the merge window itself. + .. _custodians: Custodians |