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