[RFCv2,2/2] doc: Add doc/develop/release_cycle.rst

Migrate the RelaseCycle wiki page to Sphinx.  In terms of visible
changes, we stop having a dynamic countdown to when the release is.  And
we drop the year-based statistics, that were not being kept up to date.
For the moment, we only link to statistics for v2022.07 but will add
back the historical data in a subsequent patch.

Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v2:
- New patch.  Note that I'm not including the v1.3.0 to v2022.04 stats
  here as while I can generate them, I want to make sure we're happy
  with how v2022.07 ones look as there is some manual effort involved.
  It's a reasonable amount of manual effort however for a single release.
---
 doc/develop/index.rst         |  1 +
 doc/develop/release_cycle.rst | 95 +++++++++++++++++++++++++++++++++++
 2 files changed, 96 insertions(+)
 create mode 100644 doc/develop/release_cycle.rst

Hi Tom,

On 7/12/22 11:33 AM, Tom Rini wrote:
> Migrate the RelaseCycle wiki page to Sphinx.  In terms of visible
> changes, we stop having a dynamic countdown to when the release is.  And
> we drop the year-based statistics, that were not being kept up to date.
> For the moment, we only link to statistics for v2022.07 but will add
> back the historical data in a subsequent patch.
> 
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> Changes in v2:
> - New patch.  Note that I'm not including the v1.3.0 to v2022.04 stats
>   here as while I can generate them, I want to make sure we're happy
>   with how v2022.07 ones look as there is some manual effort involved.
>   It's a reasonable amount of manual effort however for a single release.
> ---
>  doc/develop/index.rst         |  1 +
>  doc/develop/release_cycle.rst | 95 +++++++++++++++++++++++++++++++++++
>  2 files changed, 96 insertions(+)
>  create mode 100644 doc/develop/release_cycle.rst
> 
> diff --git a/doc/develop/index.rst b/doc/develop/index.rst
> index eab00a55382a..73741ceb6a2f 100644
> --- a/doc/develop/index.rst
> +++ b/doc/develop/index.rst
> @@ -12,6 +12,7 @@ General
>     codingstyle
>     designprinciples
>     process
> +   release_cycle
>  
>  Implementation
>  --------------
> diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
> new file mode 100644
> index 000000000000..dbaaa7210c4e
> --- /dev/null
> +++ b/doc/develop/release_cycle.rst
> @@ -0,0 +1,95 @@
> +Release Cycle
> +=============
> +
> +The U-Boot projects attempts to maintain a fixed, predictable Release
> +Cycle as follows:
> +
> +* We will have U-Boot releases at a fixed release interval of (approximately)
> +  every 3 months.
> +
> +* Under normal conditions the release date will be a Monday around mid-month.

I thought you aimed for the first Monday? This is what is stated below as well.

> +* Immediately following each release, there will be a "merge window" of
> +  normally 21 days, i. e. if the release was on a Monday, then the merge window
> +  will close on the Monday in the 3rd week after the release.
> +
> +  While this merge window is open, new features can be added to the U-Boot
> +  source tree. Linus Torvalds explains `here
> +  <http://thread.gmane.org/gmane.linux.kernel/729504/focus=729507>`_ and `there
> +  <http://thread.gmane.org/gmane.linux.kernel/729504/focus=729508>`_ what the
> +  term "merge window" is supposed to mean.

I think a link to the process page would be better here.

> +* After the merge window closes, no new features may be added to allow for a
> +  release candidate phase which is intended to fix bugs and regressions.
> +
> +*Note:* While we try to adhere to the release schedule, we will
> +not hesitate and take the liberty to delay a release if there are
> +good reasons, for example if there are known bugs or other technical
> +reasons.  The code will be released when it is considered ready
> +without caring too much about the announced deadline.
> +
> +*Note 2:* Even though we follow Linux ways in may respects,

nit: many

> +there are differences in the actual procedures,
> +which are documented in the :doc:`process`.
> +
> +Version Numbers
> +---------------
> +
> +Starting with the release in October 2008, the names of the releases were
> +changed from numerical release numbers without deeper meaning into a time stamp
> +based numbering.  Regular releases are now identified by names consisting of
> +the calendar year and month of the release date.  Additional fields (if
> +present) indicate release candidates or bug fix releases in "stable"
> +maintenance trees.
> +
> +Examples::
> +
> +  U-Boot v2009.11	- Release November 2009
> +  U-Boot v2009.11.1	- Release 1 in version November 2009 stable tree

From what I can tell, point releases are very unusual, except for bugs which
break booting (notably excluding security fixes). I believe the lack of point
releases is due to lack of need (since most vendors have their own branch) and
lack of bandwidth. A note here about this would be nice.

> +  U-Boot v2010.09-rc1   - Release candidate 1 for September 2010 release
> +
> +Current Status
> +--------------
> +
> +* U-Boot v2022.07 was released on Mon 11 July 2022.
> +
> +* The Merge Window for the next release (v2022.10) is **open** until -rc1
> +  release on Mon 25 July 2022.
> +
> +* Release "v2022.10" is scheduled for 03 Oct 2022.
> +
> +Future Releases
> +---------------
> +
> +.. * U-Boot v2022.10-rc1 was released on Mon 25 July 2022.
> +
> +.. * U-Boot v2022.10-rc2 was released on Mon 08 August 2022.
> +
> +.. * U-Boot v2022.10-rc3 was released on Mon 22 August 2022.
> +
> +.. * U-Boot v2022.10-rc4 was released on Mon 05 September 2022.
> +
> +.. * U-Boot v2022.10-rc5 was released on Mon 19 September 2022.

Will be? Maybe it's better to use a past release for this if you want to use
concrete dates.

> +Please note that the following dates are for information only and without
> +responsibility:
> +
> +.. Release date:  Generally first Monday of the month
> +.. End of MW = Release Date + 21 d = 3rd Monday of the month
> +
> +* "v2022.10": end of MW = Mon, Jul 25, 2022; release = Mon, Oct 03, 2022
> +
> +* "v2023.01": end of MW = Mon, Oct 24, 2022; release = Mon, Jan 09, 2023
> +
> +* "v2023.04": end of MW = Mon, Jan 30, 2022; release = Mon, Apr 03, 2023
> +
> +* "v2023.07": end of MW = Mon, Apr 24, 2023; release = Mon, Jul 03, 2023 
> +
> +Previous Releases
> +-----------------
> +
> +Note: these statistics are generated by our fork of `gitdm
> +<https://source.denx.de/u-boot/gitdm>`_, which was originally created by
> +Jonathan Corbet.
> +
> +* :doc:`statistics/u-boot-stats-v2022.07` which was released on 11 July 2022.
> 

--Sean

On Tue, Jul 12, 2022 at 11:48:49AM -0400, Sean Anderson wrote:
> Hi Tom,
> 
> On 7/12/22 11:33 AM, Tom Rini wrote:
> > Migrate the RelaseCycle wiki page to Sphinx.  In terms of visible
> > changes, we stop having a dynamic countdown to when the release is.  And
> > we drop the year-based statistics, that were not being kept up to date.
> > For the moment, we only link to statistics for v2022.07 but will add
> > back the historical data in a subsequent patch.
> > 
> > Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > Signed-off-by: Tom Rini <trini@konsulko.com>
> > ---
> > Changes in v2:
> > - New patch.  Note that I'm not including the v1.3.0 to v2022.04 stats
> >   here as while I can generate them, I want to make sure we're happy
> >   with how v2022.07 ones look as there is some manual effort involved.
> >   It's a reasonable amount of manual effort however for a single release.
> > ---
> >  doc/develop/index.rst         |  1 +
> >  doc/develop/release_cycle.rst | 95 +++++++++++++++++++++++++++++++++++
> >  2 files changed, 96 insertions(+)
> >  create mode 100644 doc/develop/release_cycle.rst
> > 
> > diff --git a/doc/develop/index.rst b/doc/develop/index.rst
> > index eab00a55382a..73741ceb6a2f 100644
> > --- a/doc/develop/index.rst
> > +++ b/doc/develop/index.rst
> > @@ -12,6 +12,7 @@ General
> >     codingstyle
> >     designprinciples
> >     process
> > +   release_cycle
> >  
> >  Implementation
> >  --------------
> > diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
> > new file mode 100644
> > index 000000000000..dbaaa7210c4e
> > --- /dev/null
> > +++ b/doc/develop/release_cycle.rst
> > @@ -0,0 +1,95 @@
> > +Release Cycle
> > +=============
> > +
> > +The U-Boot projects attempts to maintain a fixed, predictable Release
> > +Cycle as follows:
> > +
> > +* We will have U-Boot releases at a fixed release interval of (approximately)
> > +  every 3 months.
> > +
> > +* Under normal conditions the release date will be a Monday around mid-month.
> 
> I thought you aimed for the first Monday? This is what is stated below as well.

True.  And this is copy/paste (well, cp and reformat) from the wiki but
I think worth correcting inline with the conversion rather than
stand-alone.

> 
> > +* Immediately following each release, there will be a "merge window" of
> > +  normally 21 days, i. e. if the release was on a Monday, then the merge window
> > +  will close on the Monday in the 3rd week after the release.
> > +
> > +  While this merge window is open, new features can be added to the U-Boot
> > +  source tree. Linus Torvalds explains `here
> > +  <http://thread.gmane.org/gmane.linux.kernel/729504/focus=729507>`_ and `there
> > +  <http://thread.gmane.org/gmane.linux.kernel/729504/focus=729508>`_ what the
> > +  term "merge window" is supposed to mean.
> 
> I think a link to the process page would be better here.

It's been a long enough time now that yes, I think that's true.

> > +* After the merge window closes, no new features may be added to allow for a
> > +  release candidate phase which is intended to fix bugs and regressions.
> > +
> > +*Note:* While we try to adhere to the release schedule, we will
> > +not hesitate and take the liberty to delay a release if there are
> > +good reasons, for example if there are known bugs or other technical
> > +reasons.  The code will be released when it is considered ready
> > +without caring too much about the announced deadline.
> > +
> > +*Note 2:* Even though we follow Linux ways in may respects,
> 
> nit: many

Fixed.

> > +there are differences in the actual procedures,
> > +which are documented in the :doc:`process`.
> > +
> > +Version Numbers
> > +---------------
> > +
> > +Starting with the release in October 2008, the names of the releases were
> > +changed from numerical release numbers without deeper meaning into a time stamp
> > +based numbering.  Regular releases are now identified by names consisting of
> > +the calendar year and month of the release date.  Additional fields (if
> > +present) indicate release candidates or bug fix releases in "stable"
> > +maintenance trees.
> > +
> > +Examples::
> > +
> > +  U-Boot v2009.11	- Release November 2009
> > +  U-Boot v2009.11.1	- Release 1 in version November 2009 stable tree
> 
> From what I can tell, point releases are very unusual, except for bugs which
> break booting (notably excluding security fixes). I believe the lack of point
> releases is due to lack of need (since most vendors have their own branch) and
> lack of bandwidth. A note here about this would be nice.

I'll add a note about point releases being infrequent.

> > +  U-Boot v2010.09-rc1   - Release candidate 1 for September 2010 release
> > +
> > +Current Status
> > +--------------
> > +
> > +* U-Boot v2022.07 was released on Mon 11 July 2022.
> > +
> > +* The Merge Window for the next release (v2022.10) is **open** until -rc1
> > +  release on Mon 25 July 2022.
> > +
> > +* Release "v2022.10" is scheduled for 03 Oct 2022.
> > +
> > +Future Releases
> > +---------------
> > +
> > +.. * U-Boot v2022.10-rc1 was released on Mon 25 July 2022.
> > +
> > +.. * U-Boot v2022.10-rc2 was released on Mon 08 August 2022.
> > +
> > +.. * U-Boot v2022.10-rc3 was released on Mon 22 August 2022.
> > +
> > +.. * U-Boot v2022.10-rc4 was released on Mon 05 September 2022.
> > +
> > +.. * U-Boot v2022.10-rc5 was released on Mon 19 September 2022.
> 
> Will be? Maybe it's better to use a past release for this if you want to use
> concrete dates.

Note that '.. ' at the start of the line is a comment.  I'm turning the
commented out wiki markup in to commented out rST, and am aiming to make
"edit the release cycle page" part of my release flow.  The "every 2
weeks we do an RC" is something I really do put in my calendar to make
sure to do.  The wiki page doesn't get this section updated every time
since I have to dig out the tab, login, etc.  But edit two files,
commit, run release script is easier.

On 7/12/22 17:48, Sean Anderson wrote:
> Hi Tom,
>
> On 7/12/22 11:33 AM, Tom Rini wrote:
>> Migrate the RelaseCycle wiki page to Sphinx.  In terms of visible
>> changes, we stop having a dynamic countdown to when the release is.  And
>> we drop the year-based statistics, that were not being kept up to date.
>> For the moment, we only link to statistics for v2022.07 but will add
>> back the historical data in a subsequent patch.
>>
>> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> Signed-off-by: Tom Rini <trini@konsulko.com>
>> ---
>> Changes in v2:
>> - New patch.  Note that I'm not including the v1.3.0 to v2022.04 stats
>>    here as while I can generate them, I want to make sure we're happy
>>    with how v2022.07 ones look as there is some manual effort involved.
>>    It's a reasonable amount of manual effort however for a single release.
>> ---
>>   doc/develop/index.rst         |  1 +
>>   doc/develop/release_cycle.rst | 95 +++++++++++++++++++++++++++++++++++
>>   2 files changed, 96 insertions(+)
>>   create mode 100644 doc/develop/release_cycle.rst
>>
>> diff --git a/doc/develop/index.rst b/doc/develop/index.rst
>> index eab00a55382a..73741ceb6a2f 100644
>> --- a/doc/develop/index.rst
>> +++ b/doc/develop/index.rst
>> @@ -12,6 +12,7 @@ General
>>      codingstyle
>>      designprinciples
>>      process
>> +   release_cycle
>>
>>   Implementation
>>   --------------
>> diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
>> new file mode 100644
>> index 000000000000..dbaaa7210c4e
>> --- /dev/null
>> +++ b/doc/develop/release_cycle.rst
>> @@ -0,0 +1,95 @@
>> +Release Cycle
>> +=============
>> +
>> +The U-Boot projects attempts to maintain a fixed, predictable Release
>> +Cycle as follows:
>> +
>> +* We will have U-Boot releases at a fixed release interval of (approximately)
>> +  every 3 months.
>> +
>> +* Under normal conditions the release date will be a Monday around mid-month.
>
> I thought you aimed for the first Monday? This is what is stated below as well.
>
>> +* Immediately following each release, there will be a "merge window" of
>> +  normally 21 days, i. e. if the release was on a Monday, then the merge window
>> +  will close on the Monday in the 3rd week after the release.
>> +
>> +  While this merge window is open, new features can be added to the U-Boot
>> +  source tree. Linus Torvalds explains `here
>> +  <http://thread.gmane.org/gmane.linux.kernel/729504/focus=729507>`_ and `there
>> +  <http://thread.gmane.org/gmane.linux.kernel/729504/focus=729508>`_ what the
>> +  term "merge window" is supposed to mean.
>
> I think a link to the process page would be better here.
>
>> +* After the merge window closes, no new features may be added to allow for a
>> +  release candidate phase which is intended to fix bugs and regressions.
>> +
>> +*Note:* While we try to adhere to the release schedule, we will
>> +not hesitate and take the liberty to delay a release if there are
>> +good reasons, for example if there are known bugs or other technical
>> +reasons.  The code will be released when it is considered ready
>> +without caring too much about the announced deadline.
>> +
>> +*Note 2:* Even though we follow Linux ways in may respects,
>
> nit: many
>
>> +there are differences in the actual procedures,
>> +which are documented in the :doc:`process`.
>> +
>> +Version Numbers
>> +---------------
>> +
>> +Starting with the release in October 2008, the names of the releases were
>> +changed from numerical release numbers without deeper meaning into a time stamp
>> +based numbering.  Regular releases are now identified by names consisting of
>> +the calendar year and month of the release date.  Additional fields (if
>> +present) indicate release candidates or bug fix releases in "stable"
>> +maintenance trees.
>> +
>> +Examples::
>> +
>> +  U-Boot v2009.11	- Release November 2009
>> +  U-Boot v2009.11.1	- Release 1 in version November 2009 stable tree
>
>>From what I can tell, point releases are very unusual, except for bugs which
> break booting (notably excluding security fixes). I believe the lack of point
> releases is due to lack of need (since most vendors have their own branch) and
> lack of bandwidth. A note here about this would be nice.
>
>> +  U-Boot v2010.09-rc1   - Release candidate 1 for September 2010 release
>> +
>> +Current Status
>> +--------------
>> +
>> +* U-Boot v2022.07 was released on Mon 11 July 2022.
>> +
>> +* The Merge Window for the next release (v2022.10) is **open** until -rc1
>> +  release on Mon 25 July 2022.
>> +
>> +* Release "v2022.10" is scheduled for 03 Oct 2022.
>> +
>> +Future Releases
>> +---------------
>> +
>> +.. * U-Boot v2022.10-rc1 was released on Mon 25 July 2022.

%s/was/will be/g

July 11th + 3 weeks = Aug 1st.

>> +
>> +.. * U-Boot v2022.10-rc2 was released on Mon 08 August 2022.
>> +
>> +.. * U-Boot v2022.10-rc3 was released on Mon 22 August 2022.
>> +
>> +.. * U-Boot v2022.10-rc4 was released on Mon 05 September 2022.
>> +
>> +.. * U-Boot v2022.10-rc5 was released on Mon 19 September 2022.
>
> Will be? Maybe it's better to use a past release for this if you want to use
> concrete dates.
>
>> +Please note that the following dates are for information only and without
>> +responsibility:

Please note that the following dates are planned only and may be
deviated from as needed.

This sentence should be above the first date that is in the future.

>> +
>> +.. Release date:  Generally first Monday of the month
>> +.. End of MW = Release Date + 21 d = 3rd Monday of the month

This rule should be in a process section.

Best regards

Heinrich

>> +
>> +* "v2022.10": end of MW = Mon, Jul 25, 2022; release = Mon, Oct 03, 2022
>> +
>> +* "v2023.01": end of MW = Mon, Oct 24, 2022; release = Mon, Jan 09, 2023
>> +
>> +* "v2023.04": end of MW = Mon, Jan 30, 2022; release = Mon, Apr 03, 2023
>> +
>> +* "v2023.07": end of MW = Mon, Apr 24, 2023; release = Mon, Jul 03, 2023
>> +
>> +Previous Releases
>> +-----------------
>> +
>> +Note: these statistics are generated by our fork of `gitdm
>> +<https://source.denx.de/u-boot/gitdm>`_, which was originally created by
>> +Jonathan Corbet.
>> +
>> +* :doc:`statistics/u-boot-stats-v2022.07` which was released on 11 July 2022.
>>
>
> --Sean

On Tue, Jul 12, 2022 at 06:14:13PM +0200, Heinrich Schuchardt wrote:
> On 7/12/22 17:48, Sean Anderson wrote:
> > Hi Tom,
> > 
> > On 7/12/22 11:33 AM, Tom Rini wrote:
> > > Migrate the RelaseCycle wiki page to Sphinx.  In terms of visible
> > > changes, we stop having a dynamic countdown to when the release is.  And
> > > we drop the year-based statistics, that were not being kept up to date.
> > > For the moment, we only link to statistics for v2022.07 but will add
> > > back the historical data in a subsequent patch.
> > > 
> > > Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > > Signed-off-by: Tom Rini <trini@konsulko.com>
> > > ---
> > > Changes in v2:
> > > - New patch.  Note that I'm not including the v1.3.0 to v2022.04 stats
> > >    here as while I can generate them, I want to make sure we're happy
> > >    with how v2022.07 ones look as there is some manual effort involved.
> > >    It's a reasonable amount of manual effort however for a single release.
> > > ---
> > >   doc/develop/index.rst         |  1 +
> > >   doc/develop/release_cycle.rst | 95 +++++++++++++++++++++++++++++++++++
> > >   2 files changed, 96 insertions(+)
> > >   create mode 100644 doc/develop/release_cycle.rst
> > > 
> > > diff --git a/doc/develop/index.rst b/doc/develop/index.rst
> > > index eab00a55382a..73741ceb6a2f 100644
> > > --- a/doc/develop/index.rst
> > > +++ b/doc/develop/index.rst
> > > @@ -12,6 +12,7 @@ General
> > >      codingstyle
> > >      designprinciples
> > >      process
> > > +   release_cycle
> > > 
> > >   Implementation
> > >   --------------
> > > diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
> > > new file mode 100644
> > > index 000000000000..dbaaa7210c4e
> > > --- /dev/null
> > > +++ b/doc/develop/release_cycle.rst
> > > @@ -0,0 +1,95 @@
> > > +Release Cycle
> > > +=============
> > > +
> > > +The U-Boot projects attempts to maintain a fixed, predictable Release
> > > +Cycle as follows:
> > > +
> > > +* We will have U-Boot releases at a fixed release interval of (approximately)
> > > +  every 3 months.
> > > +
> > > +* Under normal conditions the release date will be a Monday around mid-month.
> > 
> > I thought you aimed for the first Monday? This is what is stated below as well.
> > 
> > > +* Immediately following each release, there will be a "merge window" of
> > > +  normally 21 days, i. e. if the release was on a Monday, then the merge window
> > > +  will close on the Monday in the 3rd week after the release.
> > > +
> > > +  While this merge window is open, new features can be added to the U-Boot
> > > +  source tree. Linus Torvalds explains `here
> > > +  <http://thread.gmane.org/gmane.linux.kernel/729504/focus=729507>`_ and `there
> > > +  <http://thread.gmane.org/gmane.linux.kernel/729504/focus=729508>`_ what the
> > > +  term "merge window" is supposed to mean.
> > 
> > I think a link to the process page would be better here.
> > 
> > > +* After the merge window closes, no new features may be added to allow for a
> > > +  release candidate phase which is intended to fix bugs and regressions.
> > > +
> > > +*Note:* While we try to adhere to the release schedule, we will
> > > +not hesitate and take the liberty to delay a release if there are
> > > +good reasons, for example if there are known bugs or other technical
> > > +reasons.  The code will be released when it is considered ready
> > > +without caring too much about the announced deadline.
> > > +
> > > +*Note 2:* Even though we follow Linux ways in may respects,
> > 
> > nit: many
> > 
> > > +there are differences in the actual procedures,
> > > +which are documented in the :doc:`process`.
> > > +
> > > +Version Numbers
> > > +---------------
> > > +
> > > +Starting with the release in October 2008, the names of the releases were
> > > +changed from numerical release numbers without deeper meaning into a time stamp
> > > +based numbering.  Regular releases are now identified by names consisting of
> > > +the calendar year and month of the release date.  Additional fields (if
> > > +present) indicate release candidates or bug fix releases in "stable"
> > > +maintenance trees.
> > > +
> > > +Examples::
> > > +
> > > +  U-Boot v2009.11	- Release November 2009
> > > +  U-Boot v2009.11.1	- Release 1 in version November 2009 stable tree
> > 
> > > From what I can tell, point releases are very unusual, except for bugs which
> > break booting (notably excluding security fixes). I believe the lack of point
> > releases is due to lack of need (since most vendors have their own branch) and
> > lack of bandwidth. A note here about this would be nice.
> > 
> > > +  U-Boot v2010.09-rc1   - Release candidate 1 for September 2010 release
> > > +
> > > +Current Status
> > > +--------------
> > > +
> > > +* U-Boot v2022.07 was released on Mon 11 July 2022.
> > > +
> > > +* The Merge Window for the next release (v2022.10) is **open** until -rc1
> > > +  release on Mon 25 July 2022.
> > > +
> > > +* Release "v2022.10" is scheduled for 03 Oct 2022.
> > > +
> > > +Future Releases
> > > +---------------
> > > +
> > > +.. * U-Boot v2022.10-rc1 was released on Mon 25 July 2022.
> 
> %s/was/will be/g

It's commented out to make it easier to add when I do the release.

Since it's clearly confused two people so far, I'll add this as well
above the first one:

.. For the next scheduled release, release candidates were made on::

And I'll also add a comment about how commented out dates are when
future rcs are planned for.

> July 11th + 3 weeks = Aug 1st.

As I stated in the release email, given next was open, I'm not extending
rc1.

> > > +.. * U-Boot v2022.10-rc2 was released on Mon 08 August 2022.
> > > +
> > > +.. * U-Boot v2022.10-rc3 was released on Mon 22 August 2022.
> > > +
> > > +.. * U-Boot v2022.10-rc4 was released on Mon 05 September 2022.
> > > +
> > > +.. * U-Boot v2022.10-rc5 was released on Mon 19 September 2022.
> > 
> > Will be? Maybe it's better to use a past release for this if you want to use
> > concrete dates.
> > 
> > > +Please note that the following dates are for information only and without
> > > +responsibility:
> 
> Please note that the following dates are planned only and may be
> deviated from as needed.

That does read better, yes, thanks.

> This sentence should be above the first date that is in the future.
> 
> > > +
> > > +.. Release date:  Generally first Monday of the month
> > > +.. End of MW = Release Date + 21 d = 3rd Monday of the month
> 
> This rule should be in a process section.

I'll follow-up with a patch to the process page.