---- 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. [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-... [2] https://governance.openstack.org/tc/resolutions/20200803-distributed-project...

-gmann

...

-- -- James Slagle --

---- 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... [2] https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-... -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-... [2] https://governance.openstack.org/tc/resolutions/20200803-distributed-project...

-gmann

...

-- -- James Slagle --

---- On Wed, 15 Feb 2023 11:59:51 -0800 James Slagle wrote ---

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.

Hi James, Just checking if you got a chance to discuss this with the TripleO team? -gmann

-- -- James Slagle --

---- On Wed, 22 Feb 2023 10:13:32 -0800 James Slagle wrote ---

On Wed, Feb 22, 2023 at 12:43 PM Ghanshyam Mann gmann@ghanshyammann.com> wrote:

...

Hi James,

Just checking if you got a chance to discuss this with the TripleO team?

Yes, I asked folks to reply here if there are any volunteers for stable/zed maintenance, or any other feedback about the approach. I do not personally know of any volunteers.

Ok. We discussed the stable/zed case in the TC meeting and decided[1] to keep stable/zed as 'supported but no maintainers' (will update this information in stable/zed README.rst file). For the master branch, you can follow the normal deprecation process mentioned in the project-team-guide[2]. I have proposed step 1 in governance to mark it deprecated, please check and we need PTL +1 on that. - https://review.opendev.org/c/openstack/governance/+/877132 NOTE: As this is deprecated and not retired yet, we still need PTL nomination for TrilpeO[3] [1] https://meetings.opendev.org/meetings/tc/2023/tc.2023-03-08-15.59.log.html#l... [2] https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-... [3] https://etherpad.opendev.org/p/2023.2-leaderless#L26 -gmann'

-- -- James Slagle --

On Wed, Mar 22, 2023 at 1:09 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:

Hi James, TripleO team,

Is there anyone volunteering to be PTL for train and wallaby maintenance? Please note we need PTL as it is deprecated (wallaby is maintained), and we have tripleo in leaderless projects - https://etherpad.opendev.org/p/2023.2-leaderless

It doesn't look like we have any other volunteers, so I'm willing to do it. At the last PTG, we discussed and it was agreed that we would switch TripleO to the distributed project leadership model. However, given the drastic change in our focus, I personally think it makes more sense to continue with the PTL model for train/wallaby stable maintenance. I would ask any project members to reply here with +1/-1 to indicate agreement. [1] https://governance.openstack.org/tc/resolutions/20200803-distributed-project... -- -- James Slagle --

On Fri, Mar 24, 2023 at 1:00 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:

---- On Fri, 24 Mar 2023 09:48:14 -0700 James Slagle wrote ---

...

On Wed, Mar 22, 2023 at 1:09 PM Ghanshyam Mann gmann@ghanshyammann.com> wrote:

...

Hi James, TripleO team,

Is there anyone volunteering to be PTL for train and wallaby maintenance? Please note we need PTL as it is deprecated (wallaby is maintained), and we have tripleo in leaderless projects - https://etherpad.opendev.org/p/2023.2-leaderless

It doesn't look like we have any other volunteers, so I'm willing to do it. At the last PTG, we discussed and it was agreed that we would switch TripleO to the distributed project leadership model. However, given the drastic change in our focus, I personally think it makes more sense to continue with the PTL model for train/wallaby stable maintenance. I would ask any project members to reply here with +1/-1 to indicate agreement.

Thanks, James, for volunteering. I think if you were thinking of the DPL model, then it will work better than PTL here. 1. You might get more people helping you with a distributed amount of work 2. we do not need to have PTL nomination/appointment work in every cycle until you want to maintain train/wallaby.

If it is ok, let's move it to the DPL model, which satisfies the governance requirement.

That WFM, and I think we can move forward with DPL since that is what the team previously agreed upon. I'll work on some governance patches. -- -- James Slagle --

Sorry, let me not agree with this approach. TripleO is a project under OpenStack governance. Any project under the governance *must* follow 4 opens [1]. At the same time, if the project happens to be maintained by a single vendor, it doesn't make it any special from any other project that has healthy contribution diversity. So community consensus can't be neglected in my opinion. While I fully understand that the main contributor of the project is quitting it and resuming to maintain only some stable branches that are currently in an Extended Maintenance, until they will be EOLed, I personally don't think that dropping content/removing later branches or releases does follow 4 opens. Even though we might not be aware of contributors willing to step in in further maintenance of the project, it doesn't mean they won't show up in some time when the word will be spread. As Ghanshyam said, the situation we've found ourselves in will be discussed during the next TC meeting and TC will return back with a decision on how to proceed with the project deprecation process. [1] https://governance.openstack.org/tc/reference/new-projects-requirements.html

This is the mailing list thread for discussion. The team is sharing how we'll be contributing to OpenStack moving forward as it relates to TripleO. For single vendor projects made up of community members who are employees of that vendor, as opposed to volunteers, then community consensus is not entirely the contributing factor to the decision. That's not to say that the TripleO community is not in consensus with the decision one way or another. It just means that out of the community members I'm aware of, there are not enough volunteers (or any) to continue maintaining TripleO after Wallaby.

For documentation purposes, I'd say that it's a single vendor project where the vendor is no longer resourcing individuals to continue maintenance of TripleO after Wallaby, and there are as of now, no volunteers to do so. As I said, if some volunteers do come forward, then the plan could change according to how those volunteers are willing to contribute.

-- -- James Slagle --

Sorry, let me not agree with this approach. TripleO is a project under OpenStack governance. Any project under the governance *must* follow 4 opens [1]. At the same time, if the project happens to be maintained by a single vendor, it doesn't make it any special from any other project that has healthy contribution diversity. So community consensus can't be neglected in my opinion. while i hesitate to disagree with my colleague i strongly agree with this statement. regardless of the makeup of the contibutor base by being listed under the grovernace of the openstack foundation and being recognised as a offical openatck porject Tripleo is not a "RedHat Project" or thrid party project and is subject to same rules and procedures as any other offical openstack project.

While I fully understand that the main contributor of the project is quitting it and resuming to maintain only some stable branches that are currently in an Extended Maintenance, until they will be EOLed, I personally don't think that dropping content/removing later branches or releases does follow 4 opens. Even though we might not be aware of contributors willing to step in in further maintenance of the project, it doesn't mean they won't show up in some time when the word will be spread. i tend to agree i think the stable/zed branch since it has been release should not be retired it should be left open so that anyone who deployed it can fix bug and maintaien it.

If its not clear by my tone below i am very much speaking in my personal capsity not in a redhat one just to be explict about that up front. On Thu, 2023-02-09 at 13:50 +0100, Dmitriy Rabotyagov wrote: this might require addiing new memeber to the core team or other changes but if there are people willing to put in the work we shoudl afford them the opertunity. its been a very long time since there was any kind fo diversity in the triplo comunity but there have been limisted contibutions form other like 99cloud although after train that sharpely decreased. https://www.stackalytics.io/?module=tripleo-group&release=train there really has not been any significant multi vendor contibution since HP stopped workign on tripleo in kilo but that does not mean there are not comunity users of this may want to maintain it instead of move there production cloud to a diffent technology. or perhaps maintain it so that they can plan to move to a diffent deployment approch in a timely manner.

As Ghanshyam said, the situation we've found ourselves in will be discussed during the next TC meeting and TC will return back with a decision on how to proceed with the project deprecation process.

[1] https://governance.openstack.org/tc/reference/new-projects-requirements.html

...

This is the mailing list thread for discussion. The team is sharing how we'll be contributing to OpenStack moving forward as it relates to TripleO. For single vendor projects made up of community members who are employees of that vendor, as opposed to volunteers, then community consensus is not entirely the contributing factor to the decision. That's not to say that the TripleO community is not in consensus with the decision one way or another. It just means that out of the community members I'm aware of, there are not enough volunteers (or any) to continue maintaining TripleO after Wallaby.

For documentation purposes, I'd say that it's a single vendor project where the vendor is no longer resourcing individuals to continue maintenance of TripleO after Wallaby, and there are as of now, no volunteers to do so. As I said, if some volunteers do come forward, then the plan could change according to how those volunteers are willing to contribute.

-- -- James Slagle --

On Thu, 2023-02-09 at 08:39 -0500, James Slagle wrote:

On Thu, Feb 9, 2023 at 8:25 AM Sean Mooney <smooney@redhat.com> wrote:

...

...

Sorry, let me not agree with this approach. TripleO is a project under OpenStack governance. Any project under the governance *must* follow 4 opens [1]. At the same time, if the project happens to be maintained by a single vendor, it doesn't make it any special from any other project that has healthy contribution diversity. So community consensus can't be neglected in my opinion. while i hesitate to disagree with my colleague i strongly agree with this statement. regardless of the makeup of the contibutor base by being listed under the grovernace of the openstack foundation and being recognised as a offical openatck porject Tripleo is not a "RedHat Project" or thrid party project and is subject to same rules and procedures as any other offical openstack project.

While I fully understand that the main contributor of the project is quitting it and resuming to maintain only some stable branches that are currently in an Extended Maintenance, until they will be EOLed, I personally don't think that dropping content/removing later branches or releases does follow 4 opens. Even though we might not be aware of contributors willing to step in in further maintenance of the project, it doesn't mean they won't show up in some time when the word will be spread. i tend to agree i think the stable/zed branch since it has been release should not be retired it should be left open so that anyone who deployed it can fix bug and

If its not clear by my tone below i am very much speaking in my personal capsity not in a redhat one just to be explict about that up front. On Thu, 2023-02-09 at 13:50 +0100, Dmitriy Rabotyagov wrote: maintaien it. this might require addiing new memeber to the core team or other changes but if there are people willing to put in the work we shoudl afford them the opertunity. its been a very long time since there was any kind fo diversity in the triplo comunity but there have been limisted contibutions form other like 99cloud although after train that sharpely decreased. https://www.stackalytics.io/?module=tripleo-group&release=train there really has not been any significant multi vendor contibution since HP stopped workign on tripleo in kilo but that does not mean there are not comunity users of this may want to maintain it instead of move there production cloud to a diffent technology. or perhaps maintain it so that they can plan to move to a diffent deployment approch in a timely manner.

Yes, leaving the branches around also seems reasonable. In whatever way that needs to be represented in terms of who, how, or if, they are maintained, I can help represent that either through docs or governance patches, whichever is deemed appropriate. i would personally update the readme wiht a statemnt that is deprecated and that limited supprot is aviable or something like that to let people know they shoudl not plan or perform new deployment on those later versions. that part of the deprecation process anyway. advertising the support status to the possible users. it might make sense to transition stable/zed to EM too if there is no intention to do addtional releases. if maintainers appear that could be reverted by them. if not its reflective of reality.