On Wed, Feb 15, 2023 at 1:55 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
---- 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?
I understand that would be ideal, as well as for the need for process. However, I'm not aware of volunteers willing to maintain stable/zed, even minimally. I will ask on IRC and ask if anyone is willing to, and if so, then to reply to this thread. -- -- James Slagle --