
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.