| Message ID | 20240517174930.1028063-1-trini@konsulko.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | Heinrich Schuchardt |
| Headers | show |
| Series | [v3,1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process" | expand |
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.
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
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(-)