Open Stack

---- On Wed, 08 Feb 2023 13:25:01 -0800  Ghanshyam Mann  wrote --- 
 >  ---- On Wed, 08 Feb 2023 10:07:23 -0800  Ghanshyam Mann  wrote --- 
 >  > 
 >  >  ---- On Wed, 08 Feb 2023 09:38:07 -0800  James Slagle  wrote --- 
 >  >  > The team of TripleO developers, reviewers, and community have no plans to do another release of TripleO, or to continue maintaining the Zed release. This means the last maintained release of TripleO is Wallaby. The plan is to continue to maintain the train and wallaby branches of TripleO repositories under the openstack namespace. We plan to continue to run existing CI on those branches, although we anticipate reducing to a minimal set of jobs in the future. Going forward, the TripleO team expects to continue involvement in other OpenStack projects, and focus on different approaches to OpenStack deployment.
 >  >  > 
 >  >  > The team is not aware of enough other community interest to continue to maintain the zed, master, and future branches of TripleO. Eventually, we will empty commit these branches with a pointer to Wallaby being the last release. If other interests do exist to maintain TripleO going forward, then those plans can adjust.
 >  >  > 
 >  >  > TripleO does not plan on nominating a PTL in the current Bobcat election cycle. If a PTL-like contact is needed for train and wallaby maintenance, then someone will be nominated. I am also not sure how to reflect this project structure change within openstack/governance, and am looking for guidance on how to do so. This type of change did not seem to exactly fit within the concepts of inactive or retired projects. I can work on the patches for governance with some direction, if anyone can provide it. Thanks, and please let us know any questions or feedback about this plan.
 > 
 > The situation is very difficult in TripleO case where:
 > 
 > * Last supported branch needs to be stable/wallaby[1]
 > * There is stable/zed but no stable/xena, stable/yoga [2]
 > * There are independent releases (16.0.0 - 18.0.0 tag) after stable/wallaby[3]
 > 
 > We were discussing these cases more in the TC channel and it seems we are in a difficult situation to find the best way to
 > deprecate/communicate the support of the released version. Either we should close stable/zed or keep it open or mark
 > stable/wallaby as last supported but what about the released after stable/wallaby?
 > 
 > As the next step, TC will discuss it in the coming next week (Feb 15) meeting and get an agreement on the steps we need to
 > do in TripleO case. Meanwhile, please hold on to removing/cleaning/EOL anything. 

We discussed it in today's TC meeting[1]. We are clear on the deprecation process for the master branch onwards which
is nothing but following the deprecation process mentioned in doc[2]. But how to handle stable/zed is challenging, a few 
of the options we discussed in the meeting are:
* Keeping stable/zed content but deprecated (how to communicate deprecation is another thing to solve)
* Remove stable/zed content with README.rst mentioning deprecation (same way as master). 
* Tag stable/zed as EM
* EOLing stable/zed

All these options are confusing for many of us too and we can imagine how confusing they will be for
consumers/users who are not part of this discussion. Also, all the above options are out of the process.

One best possible ways to solve this situation is to maintain stable/zed also. I think it should not take
much time to maintain it in a deprecated way. That way it will be a clear deprecation and we do not need
to go out of the process. Can you check if this option works for the TripleO team?

[1] https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-15-16.00.log.html#l-123
[2] https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-repository

-gmann

 > 
 > [1] https://releases.openstack.org/teams/tripleo.html
 > [2] https://github.com/openstack/tripleo-common/branches
 > [3] https://releases.openstack.org/independent.html#none-tripleo-common
 > 
 > -gmann
 > 
 >  > 
 >  > Thanks for the updates. From the governance side,
 >  > 
 >  > 1. This is the case of deprecating the project where stable releases are maintained until the last maintained stable release is EOL.
 >  > Please follow the deprecation steps mentioned in this[1] doc.
 >  > 
 >  > 2. PTL requirement:
 >  > Until the project is not retired, we should have some point of contact. It can be to continue someone as PTL or adopt the DPL
 >  > model[2] if you want to distribute the roles among more members (nit sure how much work it will be in terms of release,
 >  > security, or testing side) 
 >  > 
 >  > [1] https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-repository
 >  > [2] https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html
 >  > 
 >  > -gmann
 >  > 
 >  >  >  
 >  >  > 
 >  >  > -- 
 >  >  > -- James Slagle
 >  >  > --
 >  > 
 >  > 
 > 
 >