[v3 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 --- Changes in v3: None
Changes in v2: None
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 --- Changes in v3: - Actually commit the changes I intended for v2
Changes in v2: - Address Quentin's feedback
Cc: Heinrich Schuchardt xypron.glpk@gmx.de Cc: Quentin Schulz quentin.schulz@cherry.de --- doc/develop/devicetree/control.rst | 9 ++++++--- doc/develop/process.rst | 13 +++++++++++++ 2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index 4cc1457d4ea8..ca4fb0b5b10f 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -113,9 +113,12 @@ SoC being used via Kconfig and set `DEFAULT_DEVICE_TREE=<vendor>/<name>` when prompted by Kconfig.
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. +newly added board support then one option is that you can add the 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. Another option is that you can use use the "pick" option of +`dts/update-dts-subtree.sh` mentioned above to bring in the commits that you +need.
This should include your CPU or SoC's devicetree file. On top of that any U-Boot specific tweaks (see: :ref:`dttweaks`) can be made for your board. 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/17/24 7:49 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
Changes in v3:
- Actually commit the changes I intended for v2
Changes in v2:
- Address Quentin's feedback
Cc: Heinrich Schuchardt xypron.glpk@gmx.de Cc: Quentin Schulz quentin.schulz@cherry.de
doc/develop/devicetree/control.rst | 9 ++++++--- doc/develop/process.rst | 13 +++++++++++++ 2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index 4cc1457d4ea8..ca4fb0b5b10f 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -113,9 +113,12 @@ SoC being used via Kconfig and set `DEFAULT_DEVICE_TREE=<vendor>/<name>` when prompted by Kconfig.
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. +newly added board support then one option is that you can add the 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
I don't like the wording here because it implies we should modify the defconfig by hand, which nobody should ever do.
I could suggest: """ To do that, unselect `OF_UPSTREAM` and set `DEFAULT_DEVICE_TREE=<name>` through a Kconfig tool (e.g. `menuconfig`). """
In any case, this is wording is not added in this patch, so I guess we could fix it in another patch as well, making this remark not a "blocker".
+prompted by Kconfig. Another option is that you can use use the "pick" option of +`dts/update-dts-subtree.sh` mentioned above to bring in the commits that you +need.
This should include your CPU or SoC's devicetree file. On top of that any U-Boot specific tweaks (see: :ref:`dttweaks`) can be made for your board. 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.
Reviewed-by: Quentin Schulz quentin.schulz@cherry.de
Thanks, Quentin
On Tue, May 21, 2024 at 11:27:36AM +0200, Quentin Schulz wrote:
Hi Tom,
On 5/17/24 7:49 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
Changes in v3:
- Actually commit the changes I intended for v2
Changes in v2:
- Address Quentin's feedback
Cc: Heinrich Schuchardt xypron.glpk@gmx.de Cc: Quentin Schulz quentin.schulz@cherry.de
doc/develop/devicetree/control.rst | 9 ++++++--- doc/develop/process.rst | 13 +++++++++++++ 2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index 4cc1457d4ea8..ca4fb0b5b10f 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -113,9 +113,12 @@ SoC being used via Kconfig and set `DEFAULT_DEVICE_TREE=<vendor>/<name>` when prompted by Kconfig. 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. +newly added board support then one option is that you can add the 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
I don't like the wording here because it implies we should modify the defconfig by hand, which nobody should ever do.
I could suggest: """ To do that, unselect `OF_UPSTREAM` and set `DEFAULT_DEVICE_TREE=<name>` through a Kconfig tool (e.g. `menuconfig`). """
In any case, this is wording is not added in this patch, so I guess we could fix it in another patch as well, making this remark not a "blocker".
Yes, I agree that would be a better way to explain things here.
Hi Tom,
On 5/17/24 7:49 PM, Tom Rini wrote:
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
Changes in v3: None
Changes in v2: None
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
Wondering if we shouldn't put:
Differences to the Linux Development Process
section under the "Phases of the development process" section as well?
Otherwise,
Reviewed-by: Quentin Schulz quentin.schulz@cherry.de
Thanks! Quentin
On Tue, May 21, 2024 at 11:23:01AM +0200, Quentin Schulz wrote:
Hi Tom,
On 5/17/24 7:49 PM, Tom Rini wrote:
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
Changes in v3: None
Changes in v2: None
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
Wondering if we shouldn't put:
Differences to the Linux Development Process
section under the "Phases of the development process" section as well?
I don't know. I thought not when I first did this patch. I still thought not as I started this reply. And then I re-read the section again and, well, maybe? Or maybe it would be better to integrate the contents of that section in to other sections, and rework it a bit too as it's not quite correct either. For example, I feel like the majority of new patches posted in the merge window (even at the start) end up in the upcoming next branch.
participants (2)
-
Quentin Schulz -
Tom Rini