Clarify SCM and release requirements

[mariolenz]

SUMMARY

We require that all collections MUST have a public SCM repository.

Actually, most people will use git nowadays but in theory, they could use any obscure SCM as long as the repo is publicly available.

This means that we might have to deal with a SCM we don't know and our tooling doesn't support. Therefor, I suggest requiring git instead of generic SCM repositories.

ISSUE TYPE

• Docs Pull Request

COMPONENT NAME

collection_checklist.md
collection_requirements.rst

ADDITIONAL INFORMATION

ansible-community/community-topics#148 (comment)

cc @felixfontein

[gotmax23]

Currently, I don't think we have any tooling that depends on the presence of a Git repository. I'm okay with this change, but I think it should be made in conjunction with the proposed wording and enforcement changes of the release tagging rule (ansible-community/community-topics#148) to clarify the reason for requiring a git repository and so we don't have to vote twice.

[mariolenz]

I'm okay with this change, but I think it should be made in conjunction with the proposed wording and enforcement changes of the release tagging rule (ansible-community/community-topics#148) to clarify the reason for requiring a git repository and so we don't have to vote twice.

I'm not sure what's better, having this as a change on it's own or do it in conjunction with ansible-community/community-topics#148. I'm fine with both options.

[mariolenz]

@gotmax23

If there's consensus to handle this separately, I can create a separate PR.

I might be wrong, but I don't think we need to handle this seperately. I've copied your suggestion over to ansible-community/community-topics#148 so it's not lost and will close this PR.

[felixfontein]

I would have just updated this PR with the new suggestion, but we can also have a new one, or first continue discussing it in community-topics. Whatever you prefer :)

[mariolenz]

I would have just updated this PR with the new suggestion, but we can also have a new one, or first continue discussing it in community-topics. Whatever you prefer :-)

@felixfontein @gotmax23 I've re-opened the PR, merged the suggestion and changed the title.

[felixfontein]

I think this looks good. Maybe let's wait a few more days for feedback, and if there is none start a vote? Or do you think we should already start voting sooner?

[mariolenz]

Maybe let's wait a few more days for feedback, and if there is none start a vote? Or do you think we should already start voting sooner?

I've opened a vote because this has been (basically) discussed in the last community meeting iirc, so people should know about this and already had a couple of days to give feedback.

I have given an end date that's a few days later than the usual 1 week so people have more time to react, though.

[briantist]

While I'm not opposed to this sentence, it seems unlikely we'll ever make the tooling support other SCM software unless a collection that uses it exists, and if we're preventing it from being added based on that, I doubt we'd ever support them.

I'd also like to know what tooling specifically.. though it doesn't have to be listed in this doc.

[mariolenz]

I'd also like to know what tooling specifically.. though it doesn't have to be listed in this doc.

Probably collection_prep. I'm not an expert on this tool, but I think it won't work with non-git repositories.

@felixfontein Did you have anything else in mind when saying that we can potentially add more SCMs to the list once our tooling supports them?

[gotmax23]

I'd also like to know what tooling specifically.. though it doesn't have to be listed in this doc.

See ansible-community/community-topics#148 (comment). My idea was that we'd set up an automated check to ensure that new collection Galaxy releases are tagged in the respective collection's repository. @felixfontein pointed out that would fall flat if we didn't actually mandate that collections use a git repository.

it seems unlikely we'll ever make the tooling support other SCM software unless a collection that uses it exists, and if we're preventing it from being added based on that, I doubt we'd ever support them.

I guess if a new collection wanted to use some other SCM, that's when we'd consider allowing it.

[felixfontein]

Probably collection_prep. I'm not an expert on this tool, but I think it won't work with non-git repositories.

I've never used that in any collections I'm working on :)

I was mainly referring to antsibull, and potential future CI / tooling in the ansible-build-data repository. Right now there's nothing in there which depends on collections using git repos, but when we want to start looking at the tags for the releases (and from the discussions, this could very likely be the case), we need to limit the SCMs to something we actively want to (and can) support.

About extending the list of allowed SCMs: we probably only will do it when we have a collection that wants to be included that doesn't use git. I'm not sure whether this will happen anytime soon, but if it does happen, it probably depends a lot on the SCM how it will continue.

[Andersson007]

@mariolenz thanks for the improvement! @gotmax23 @felixfontein @briantist thanks for reviewing!