Open Stack

 ---- 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.

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
 >