[PATCH 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process"
These sections which talk about the different phases of the development process should be using the subsubheading identifier.
Signed-off-by: Tom Rini trini@konsulko.com --- Cc: Heinrich Schuchardt xypron.glpk@gmx.de --- doc/develop/process.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/develop/process.rst b/doc/develop/process.rst index 92477d05dd85..a66540a698c1 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
Document the logic of when we do a full resync of the device trees used by OF_UPSTREAM as well as that cherry-picking is allowed as needed.
Signed-off-by: Tom Rini trini@konsulko.com --- Cc: Heinrich Schuchardt xypron.glpk@gmx.de --- doc/develop/process.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/doc/develop/process.rst b/doc/develop/process.rst index a66540a698c1..0542b3fc1245 100644 --- a/doc/develop/process.rst +++ b/doc/develop/process.rst @@ -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
Hi Tom,
On 5/16/24 10:34 PM, Tom Rini wrote:
Document the logic of when we do a full resync of the device trees used by OF_UPSTREAM as well as that cherry-picking is allowed as needed.
Signed-off-by: Tom Rini trini@konsulko.com
Cc: Heinrich Schuchardt xypron.glpk@gmx.de
doc/develop/process.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/doc/develop/process.rst b/doc/develop/process.rst index a66540a698c1..0542b3fc1245 100644 --- a/doc/develop/process.rst +++ b/doc/develop/process.rst @@ -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.
Can we provide an example on how to cherry-pick those changes with a command line?
Additionally, in doc/develop/devicetree/control.rst we say:
""" However, if `dts/upstream/` hasn't yet received devicetree source file for your newly added board support then you can add corresponding devicetree source file as `arch/<arch>/dts/<name>.dts`. To select that add `# CONFIG_OF_UPSTREAM is not set` and set `DEFAULT_DEVICE_TREE=<name>` when prompted by Kconfig. """
But now we have a second option, cherry-picking upstream changes instead, so I assume we should document it there as well (or cross-reference?).
Looks good to me otherwise, thanks for clarifying this new process.
Cheers, Quentin
On Fri, May 17, 2024 at 10:35:43AM +0200, Quentin Schulz wrote:
Hi Tom,
On 5/16/24 10:34 PM, Tom Rini wrote:
Document the logic of when we do a full resync of the device trees used by OF_UPSTREAM as well as that cherry-picking is allowed as needed.
Signed-off-by: Tom Rini trini@konsulko.com
Cc: Heinrich Schuchardt xypron.glpk@gmx.de
doc/develop/process.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/doc/develop/process.rst b/doc/develop/process.rst index a66540a698c1..0542b3fc1245 100644 --- a/doc/develop/process.rst +++ b/doc/develop/process.rst @@ -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.
Can we provide an example on how to cherry-pick those changes with a command line?
This is covered in doc/develop/devicetree/control.rst already so I'd rather not, in this document, which is currently just "why" we do things. If we need full examples and not just how to use, we should expand "Resyncing with devicetree-rebasing" in the other document I think.
Additionally, in doc/develop/devicetree/control.rst we say:
""" However, if `dts/upstream/` hasn't yet received devicetree source file for your newly added board support then you can add corresponding devicetree source file as `arch/<arch>/dts/<name>.dts`. To select that add `# CONFIG_OF_UPSTREAM is not set` and set `DEFAULT_DEVICE_TREE=<name>` when prompted by Kconfig. """
But now we have a second option, cherry-picking upstream changes instead, so I assume we should document it there as well (or cross-reference?).
Looks good to me otherwise, thanks for clarifying this new process.
Thanks for spotting that part, yes, I'll go re-word that as well.
participants (2)
-
Quentin Schulz -
Tom Rini