[associated vote ended on 2022-12-08] Unmaintained collection: cisco.nso

[mariolenz]

Summary

The cisco.nso collection looks unmaintained / abandoned, it has:

• no new commits since end of January 2021
• no release on Galaxy since version 1.0.3 2 years ago
• no CI run for 2 years
• no reaction on Unmaintained collection: Removal from Ansible (communtiy) package CiscoDevNet/ansible-nso#10
• no reaction on Collection Requirements Violation - Repository Management CiscoDevNet/ansible-nso#11

[Andersson007]

@mariolenz thanks for creating the issue!
I think no new commits and no releases are themselves not indicators of absence of maintenance if there are no open issues/PRs not reviewed/merged, etc.
IMO we should highlight that the violation, in this particular case, is not running CI and those things spotted by @felixfontein in CiscoDevNet/ansible-nso#4. So the maintainers have to fix them to avoid exclusion.
What do you think?

[mariolenz]

@Andersson007

I think no new commits and no releases are themselves not indicators of absence of maintenance if there are no open issues/PRs not reviewed/merged, etc.

I'm not sure if I agree. English isn't my first language, so maybe I'm putting this badly but I should say that no new commits and releases are indicators of absence of maintenance. Just indicators. Not strong ones and all by themselves not sufficient. Because, as you say, there may be simply no need because nobody opened any issues or PRs.

IMO we should highlight that the violation, in this particular case, is not running CI and those things spotted by @felixfontein in CiscoDevNet/ansible-nso#4. So the maintainers have to fix them to avoid exclusion. What do you think?

Well, if the collection ist still maintained the maintainers hopefully follow the link to this discussion and see that we consider those the main points. If it's not maintained any more, it wouldn't help to point this out in the issue, would it?

FYI, there's also CiscoDevNet/ansible-nso#11 since today.

[Andersson007]

@mariolenz

I should say that no new commits and releases are indicators of absence of maintenance. Just indicators. Not strong ones and all by themselves not sufficient.

Yep, i agree, thanks for clarifying

Well, if the collection ist still maintained the maintainers hopefully follow the link to this discussion and see that we consider those the main points. If it's not maintained any more, it wouldn't help to point this out in the issue, would it?

Yep, you're right, if they appear we could take a closer look at the collection and elaborate more on stuff to fix. To create a full list of must-fix things would be maybe a waste of energy at this point.

Thanks

[gotmax23]

I'm +1 to considering this collection unmaintained and moving forward with the removal process. The collection has no recent activity, as @mariolenz said, and they've ignored reports of collection requirements violations.

[mariolenz]

@Andersson007 @felixfontein What do you think, is it time yet to start a vote and announce it in Bullhorn yet? The issue in the collection’s issue tracker was created 2022-10-26 and was announced in Bullhorn 2022-10-28.

I could open a vote today and let it end next week Thursday. This way, we could get it into this week's Bullhorn issue and the result into the next one.

Or should we wait another week?

[felixfontein]

I think it's ok to wait one more week. (The US is pretty busy with thanksgiving anyway.)

[mariolenz]

The US is pretty busy with thanksgiving anyway.

Good point. Then let's wait another week befor moving forward with the removal process.

[mariolenz]

Vote is happening in #165

[mariolenz]

I counted votes: 7 x +1 from SC (mariolenz Andersson007 felixfontein markuman gotmax23 russoz gundalow)

[Andersson007]

I counted votes: 7 x +1 from SC (mariolenz Andersson007 felixfontein markuman gotmax23 russoz gundalow)

I counted the same number. The quorum has been reached.

[mariolenz]

In that case the proposal has been accepted and we will announce to remove the collection from Ansible 9.

Thanks all!

[gotmax23]

Closing in favor of ansible-community/ansible-build-data#190.