-
Notifications
You must be signed in to change notification settings - Fork 49
Describe how collections can be removed from the Ansible package #201
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for putting this together @felixfontein !
It's only the Y = X+1 part I'm a little unclear on, the rest I'd feel comfortable approving now as a first set of rules that can be iterated on.
@felixfontein thanks for starting this!
What do you think? |
So you mean for every case (like unmaintained collection) there are multiple subsections (removal, stop removal, re-adding), every one of them following this stucture? |
Co-authored-by: Andrew Klychkov <aaklychkov@mail.ru>
Ooops, wrong PR... |
yep |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this is a great start. I made a few suggestions to clarify and simplify the language. I'd be happy to review the wording again as we keep moving forward.
Co-authored-by: Alicia Cozine <879121+acozine@users.noreply.github.com>
Co-authored-by: Alicia Cozine <879121+acozine@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@felixfontein great job, thanks!
Couple of cosmetic things from me. Generally the process LGTM
Co-authored-by: Andrew Klychkov <aaklychkov@mail.ru>
Co-authored-by: Andrew Klychkov <aaklychkov@mail.ru>
Co-authored-by: Andrew Klychkov <aaklychkov@mail.ru>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@acozine @briantist @mariolenz any more comments on this? If not, let's start a vote in community-topics. |
I'm good with a vote |
removal_from_ansible.rst
Outdated
|
||
The announcement mentioned below must state the reasons for the proposed removal and alert maintainers and the Ansible community that, to prevent the removal, the collection urgently needs new maintainers who can fix the problems. | ||
|
||
#. Announce upcoming removal in Ansible X+1 as described in :ref:`announce_removal`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The internal references and links don't work for me. This one, for example, links to removal_from_ansible.rst#id1 although I think it should link to removal_from_ansible.rst#announcing-upcoming-removal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unfortunately a general problem with GitHub's RST renderer, you can also see it in action here: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#collection-infrastructure Basically GH does not support :ref:
, see github/markup#122.
I've tried to fix the references by converting them to links. Now rst2html5 from docutils properly handles them, but GitHub's rest2html does not: it shows links (https://github.com/ansible-collections/overview/blob/130944d4e056ec829f97a48de223522929292201/removal_from_ansible.rst), but uses the wrong hrefs so the links do nothing. This is really sad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unfortunately a general problem with GitHub's RST renderer
In that case, should we keep it as it is and vote? The links are broken on GitHub but the content is OK. Maybe we find a way to fix this later. Or GitHub fixes its RST renderer if we're lucky.
This is really sad.
Definitely.
The internal references don't work for me (see above). Is this a GitHub issue or some problem on my side? Anyway, I've read through the document again and the text looks OK to me. So start a vote in community-topics if you want to. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good. I added some ideas for making it better.
#. Re-add collection to ``collection-meta.yaml`` (``https://github.com/ansible-community/ansible-build-data/blob/main/<X>/collection-meta.yaml``). | ||
#. If the removal was announced in the Ansible changelog for a version that has not yet been released (``https://github.com/ansible-community/ansible-build-data/blob/main/<X>/changelog.yaml``), remove the announcement. | ||
|
||
Broken collections |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would still add a heading here for "Reasons we remove collections" and then make "Broken collections" and "Unmaintained collections" sub-sections of that. But we can do this after the content is voted on and merged in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Alicia's points here
Co-authored-by: Alicia Cozine <879121+acozine@users.noreply.github.com>
Co-authored-by: Mario Lenz <m@riolenz.de>
Thanks @gotmax23 and @mariolenz! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to this once existing review comments have been addresses.
#. Re-add collection to ``collection-meta.yaml`` (``https://github.com/ansible-community/ansible-build-data/blob/main/<X>/collection-meta.yaml``). | ||
#. If the removal was announced in the Ansible changelog for a version that has not yet been released (``https://github.com/ansible-community/ansible-build-data/blob/main/<X>/changelog.yaml``), remove the announcement. | ||
|
||
Broken collections |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Alicia's points here
Hi @ansible-collections/steering-committee, please read and approve or state objections for this PR so we can move ahead. Thanks. |
+1 to merging now. We can make it progressively better over time. |
It's still |
Sorry, I completely forgot last week to remove the |
+1 to merging this now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 from my side
Please use the voting issue (ansible-community/community-topics#90) to vote on this, and not this PR. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
Approved by ansible-community/community-topics#90 |
Thanks everyone! |
SUMMARY
I wrote this up based on the discussion we had at today's community meeting. The aim of this PR is to have some basic rules on which collections can be removed so we can vote on them soon and establish them. The aim is not to have a complete list of rules. I expect we will have more discussions and additional situations added to this document in follow-up PRs.
The two processes described here are modelled after two explicit examples:
community.kubevirt is currently broken and does not work as inclued in Ansible 5, since it requires community.kubernetes < 2.0.0, while Ansible 5 includes community.kubernetes >= 2.0.0. Adjusting the collection to community.kubernetes >= 2.0.0 or kubernetes.core >= 2.0.0 have been unsuccessful and stagnated (Get working with k8s.core 2 and above community.kubevirt#34 has been inactive for six months now). Since more breakage could happen with kubernetes.core 3.0.0, we do not want to keep this collection in Ansible without active maintainers who promise to keep the code working with current versions. The first of the two processes will apply to this collection.
community.google seems to be unmaintained. It is unclear whether it still works (there is no indication it does, but also no indication that it does not). It uses very old and outdated dependencies, and CI has been broken for a long time before it was automatically disabled months ago. (The broken part was sanity checks only, unit tests were passing.) Since there has been no community interaction on this for a long time (there is no issue except some generic announcements, and there are no PRs), and there has never been any real community work on this collection, it is more likely that nobody is using it and it might even be totally broken without anyone realizing. The second process is written with this collection in mind. It gives community and users of this collection a chance to say that they use it and to step up helping it, but if nobody does, we have a process to remove it. (Also if it is removed folks can still manually install it.)
ISSUE TYPE
COMPONENT NAME
removal_from_ansible.rst