Open Stack

On Wed, Jul 26, 2023 at 7:46 PM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

>  ---- On Wed, 26 Jul 2023 10:29:37 -0700  Ghanshyam Mann  wrote ---
>  >  ---- On Wed, 26 Jul 2023 10:11:07 -0700  Jeremy Stanley  wrote ---
>  >  > On 2023-07-26 18:41:05 +0200 (+0200), Alfredo Moralejo Alonso wrote:
>  >  > [...]
>  >  > > For clarity, will this new model affect all the OpenStack projects
>  >  > > or is it an alternative to the current EM model based on each
>  >  > > project election?
>  >  > [...]
>  >  >
>  >  > All OpenStack projects. The proposed idea is to get rid of the
>  >  > "Extended Maintenance" phase for stable/.* branches completely, so
>  >  > once normal maintenance ends for a branch it is renamed to
>  >  > unmaintained/.* to more clearly communicate the lack of official
>  >  > maintenance by its corresponding developer/reviewer team. Make sure
>  >  > you read the current text of the proposed resolution at
>  >  > https://review.opendev.org/888771 though. It does say "The phase of
>  >  > Extended Maintenance for a branch is renamed to Unmaintained." and
>  >  > makes no mention of introducing per-project schedules for the end of
>  >  > the "maintained" phase.
>  >  >
>  >  > Since end of "maintained" is project-wide per the chart at
>  >  > https://releases.openstack.org/ it stands to reason that projects
>  >  > will continue to coordinate the end date of that phase. For example,
>  >  > 2023.1 a.k.a. "Antelope" is expected to end its maintained phase
>  >  > around 2024-09-22, so if the current proposal were to be approved by
>  >  > the TC, that means that around 2024-09-22 the stable/2023.1 branches
>  >  > of all branched projects would be deleted and new
>  >  > unmaintained/2023.1 branches created from their prior state. Anyone
>  >  > pulling from the old stable/2023.1 branches would get an error from
>  >  > Git that the remote no longer exists, and they would need to start
>  >  > checking out unmaintained/2023.1 instead if they intended to
>  >  > continue using that source past the end of the maintained phase.
>  >
>  > As Jeremy mentioned, it will apply to all the projects and replace the
> existing
>  > "Extended Maintenance" model. Once we merge the TC resolution, we will
>  > also update the project-team-guide document for details.
>  >
>  > Along with the "stable/2023.1 -> unmaintained/2023.1" transition (which
> is
>  > our SLURP release model), TC resolution proposes the plan for the
> existing EM
>  > branches also (currently, those are stable/rocky till stable/xena ).
> Considering they
>  > are 6-month upgradable releases only (pre-SLURP model releases), the
> current proposal
>  > for existing EM branches is to automatically move only the three latest
> EM branches to
>  > unmaintained, which will be:
>  >
>  > 1. stable/xena ->  unmaintained/xena
>  > 2. stable/wallaby -> unmaintained/wallaby
>  > 3. stable/victoria -> unmaintained/victoria
>  >
>  > If the project team finds that there are no maintainers or interest in
> those three branches, it is
>  > possible to move them to EOL.
>
> To clarify, after moving them to 'unmaintained' if there is no
> maintainers/interest, then the project
> team can propose moving them to EOL (but let's see how it goes and we
> should give enough time to
> communicate it to operators/users).
>
> -gmann
>
>
Thanks both for the explanations!

Alfredo


>  >
>  > This is the in-progress proposal, feel free to comment on Gerrit if you
> have any feedback or improvement
>  > points in this.
>  >
>  > -gmann
>  >
>  >  > --
>  >  > Jeremy Stanley
>  >  >
>  >
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230726/89ce5869/attachment.htm>