[tc][all][searchlight ] Retiring the Searchlight project
Hello Everyone, As you know, Searchlight is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1]. TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Searchlight repos except few gate fixes or community goal commits[3]. Based on all these checks and no maintainer for Searchlight, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5]. If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Searchlight will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance. With that thanks to Searchlight contributors and PTLs for maintaining this project. [1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=searchlight-group&metric=commits [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repositor... [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-rep... -gmann
On 11/10/20 8:15 PM, Ghanshyam Mann wrote:
Hello Everyone,
As you know, Searchlight is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1].
TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Searchlight repos except few gate fixes or community goal commits[3].
Based on all these checks and no maintainer for Searchlight, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5].
If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Searchlight will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance.
With that thanks to Searchlight contributors and PTLs for maintaining this project.
[1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=searchlight-group&metric=commits [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repositor... [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-rep...
-gmann
Hi, When some projects are being removed, does this mean that there's going to be a community effort to remove the dependency on the clients? IMO, it really should be done. I'm thinking about: - congressclient - qinlinclient - searchlightclient - karborclient All of the above only reached Debian because they were dependencies of other projects... Cheers, Thomas Goirand
---- On Tue, 10 Nov 2020 15:12:33 -0600 Thomas Goirand <zigo@debian.org> wrote ----
On 11/10/20 8:15 PM, Ghanshyam Mann wrote:
Hello Everyone,
As you know, Searchlight is a leaderless project for the Wallaby cycle, which means there is no PTL candidate to lead it in the Wallaby cycle. 'No PTL' and no liaisons for DPL model is one of the criteria which triggers TC to start checking the health, maintainers of the project for dropping the project from OpenStack Governance[1].
TC discussed the leaderless project in PTG[2] and checked if the project has maintainers and what activities are done in the Victoria development cycle. It seems no functional changes in Searchlight repos except few gate fixes or community goal commits[3].
Based on all these checks and no maintainer for Searchlight, TC decided to drop this project from OpenStack governance in the Wallaby cycle. Ref: Mandatory Repository Retirement resolution [4] and the detailed process is in the project guide docs [5].
If your organization product/customer use/rely on this project then this is the right time to step forward to maintain it otherwise from the Wallaby cycle, Searchlight will move out of OpenStack governance by keeping their repo under OpenStack namespace with an empty master branch with 'Not Maintained' message in README. If someone from old or new maintainers shows interest to continue its development then it can be re-added to OpenStack governance.
With that thanks to Searchlight contributors and PTLs for maintaining this project.
[1] https://governance.openstack.org/tc/reference/dropping-projects.html [2] https://etherpad.opendev.org/p/tc-wallaby-ptg [3] https://www.stackalytics.com/?release=victoria&module=searchlight-group&metric=commits [4] https://governance.openstack.org/tc/resolutions/20190711-mandatory-repositor... [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-rep...
-gmann
Hi,
When some projects are being removed, does this mean that there's going to be a community effort to remove the dependency on the clients? IMO, it really should be done. I'm thinking about:
Yes, as part of the retirement process all deliverables under the project needs to be removed and before removal we do: 1. Remove all dependencies. 2. Refactor/remove the gate job dependency also. 3. Remove the code from the retiring repo.
- congressclient
This is already retired in Victoria cycle[1].
- qinlinclient This client is also on the list of retirement in Wallaby so let's see if no maintainer then we will retire this too[2].
- searchlightclient This is one of the deliverables under the Searchlight project so we will be retiring this repo alsp.
- karborclient Ditto[3].
[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014292.htm... [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018638.... [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018643.... -gmann
All of the above only reached Debian because they were dependencies of other projects...
Cheers,
Thomas Goirand
Ghanshyam Mann wrote:
Yes, as part of the retirement process all deliverables under the project needs to be removed and before removal we do: 1. Remove all dependencies. 2. Refactor/remove the gate job dependency also. 3. Remove the code from the retiring repo.
I think Thomas's point was that some of those retired deliverables are required by non-retired deliverables, like: - python-qinlingclient being required by mistral-extra - python-searchlightclient and python-karborclient being required by openstackclient and python-openstackclient We might need to remove those features/dependencies first, which might take time... -- Thierry Carrez (ttx)
On Thu, Nov 12, 2020 at 7:31 PM Thierry Carrez <thierry@openstack.org> wrote:
Ghanshyam Mann wrote:
Yes, as part of the retirement process all deliverables under the project needs to be removed and before removal we do: 1. Remove all dependencies. 2. Refactor/remove the gate job dependency also. 3. Remove the code from the retiring repo.
I think Thomas's point was that some of those retired deliverables are required by non-retired deliverables, like:
- python-qinlingclient being required by mistral-extra
- python-searchlightclient and python-karborclient being required by openstackclient and python-openstackclient
We might need to remove those features/dependencies first, which might take time...
Yeah, I think so too. Regarding OSC, python-openstackclient does not depend on python-searchlightclient. "openstackclient" is a wrapper project which allows us to install all OSC plugins along with the main OSC. We can drop retired OSC plugins from the "openstackclient" requirements. -- Akihiro Motoki (irc: amotoki)
-- Thierry Carrez (ttx)
On Thu, 2020-11-12 at 21:42 +0900, Akihiro Motoki wrote: On Thu, Nov 12, 2020 at 7:31 PM Thierry Carrez <thierry@openstack.org> wrote:
Ghanshyam Mann wrote:
Yes, as part of the retirement process all deliverables under the project needs to be removed and before removal we do: 1. Remove all dependencies. 2. Refactor/remove the gate job dependency also. 3. Remove the code from the retiring repo.
I think Thomas's point was that some of those retired deliverables are required by non-retired deliverables, like:
- python-qinlingclient being required by mistral-extra
- python-searchlightclient and python-karborclient being required by openstackclient and python-openstackclient
We might need to remove those features/dependencies first, which might take time...
Yeah, I think so too. Regarding OSC, python-openstackclient does not depend on python-searchlightclient. "openstackclient" is a wrapper project which allows us to install all OSC plugins along with the main OSC. We can drop retired OSC plugins from the "openstackclient" requirements. We only depend on them for documentation purposes. We'll just remove those docs. Stephen
---- On Thu, 12 Nov 2020 04:29:11 -0600 Thierry Carrez <thierry@openstack.org> wrote ----
Ghanshyam Mann wrote:
Yes, as part of the retirement process all deliverables under the project needs to be removed and before removal we do: 1. Remove all dependencies. 2. Refactor/remove the gate job dependency also. 3. Remove the code from the retiring repo.
I think Thomas's point was that some of those retired deliverables are required by non-retired deliverables, like:
- python-qinlingclient being required by mistral-extra
- python-searchlightclient and python-karborclient being required by openstackclient and python-openstackclient
We might need to remove those features/dependencies first, which might take time...
Yes, that is part of the retirement process, before we remove the project code all dependencies will be taken care same way we did in past (congress project etc). Few dependencies like from OSC it is easy but few like integrated features can be complex and will take time. -gmann
-- Thierry Carrez (ttx)
On 11/12/20 11:29 AM, Thierry Carrez wrote:
Ghanshyam Mann wrote:
Yes, as part of the retirement process all deliverables under the project needs to be removed and before removal we do: 1. Remove all dependencies. 2. Refactor/remove the gate job dependency also. 3. Remove the code from the retiring repo.
I think Thomas's point was that some of those retired deliverables are required by non-retired deliverables, like:
- python-qinlingclient being required by mistral-extra
- python-searchlightclient and python-karborclient being required by openstackclient and python-openstackclient
We might need to remove those features/dependencies first, which might take time...
Exactly, thanks for correcting my (very) poor wording. Cheers, Thomas Goirand (zigo)
---- On Thu, 12 Nov 2020 10:43:57 -0600 Thomas Goirand <zigo@debian.org> wrote ----
On 11/12/20 11:29 AM, Thierry Carrez wrote:
Ghanshyam Mann wrote:
Yes, as part of the retirement process all deliverables under the project needs to be removed and before removal we do: 1. Remove all dependencies. 2. Refactor/remove the gate job dependency also. 3. Remove the code from the retiring repo.
I think Thomas's point was that some of those retired deliverables are required by non-retired deliverables, like:
- python-qinlingclient being required by mistral-extra
- python-searchlightclient and python-karborclient being required by openstackclient and python-openstackclient
We might need to remove those features/dependencies first, which might take time...
Exactly, thanks for correcting my (very) poor wording.
Updates: Most of the retirement patches are merged now (next is to merge the project-config and governance patch), please merge all the dependencies removal patches to avoid any break in respective project gate/features. https://review.opendev.org/q/topic:%22retire-searchlight%22+(status:open%20O...) -gmann
Cheers,
Thomas Goirand (zigo)
participants (5)
-
Akihiro Motoki
-
Ghanshyam Mann
-
Stephen Finucane
-
Thierry Carrez
-
Thomas Goirand