Open Stack

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

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