On Wed, Jul 26, 2023 at 7:46 PM Ghanshyam Mann gmann@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:
- stable/xena -> unmaintained/xena
- stable/wallaby -> unmaintained/wallaby
- 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