Hello, I also agree with the merging of everything into one repo. When I discovered those repos, I was surprised that it was split into several repos. Keeping a structure with contrib/ folder like Thierry example is the best imo. You said it, it will ease discovery of tools, but also maintenance. Cheers. Le ven. 28 août 2020 à 12:06, Thierry Carrez <thierry@openstack.org> a écrit :
Sean McGinnis wrote:
[...] Since these are now owned by an official SIG, we can move this content back under the openstack/ namespace. That should help increase visibility somewhat, and make things look a little more official. It will also allow contributors to tooling to get recognition for contributing to an import part of the OpenStack ecosystem.
I do think it's can be a little more difficult to find things spread out over several repos though. For simplicity with finding tooling, as well as watching for reviews and helping with overall maintenance, I would like to move all of these under a common openstack/osops. Under that repo, we can then have a folder structure with tools/logging, tools/monitoring, etc.
Also the original setup[1] called for moving things from one repo to another as they get more mature, which loses history. So I agree a single repository is better.
However, one benefit of the original setup was that it made it really low-friction to land half-baked code in the osops-tools-contrib repository. The idea was to encourage tools sharing, rather than judge quality or curate a set. I think it's critical for the success of OSops that operator code can be brought in with very low friction, and curation can happen later.
If we opt for a theme-based directory structure, we could communicate that a given tool is in "unmaintained/use-at-your-own-risk" status using metadata. But thinking more about it, I would suggest we keep a low-friction "contrib/" directory in the repo, which more clearly communicates "use at your own risk" for anything within it. Then we could move tools under the "tools/" directory structure if a community forms within the SIG to support and improve a specific tool. That would IMHO allow both low-friction landing *and* curation to happen.
[...] Please let me know if there are any objects to this plan. Otherwise, I will start cleaning things up and getting it staged in a new repo to be imported as an official repo owned by the SIG.
I like it!
[1] https://wiki.openstack.org/wiki/Osops
-- Thierry Carrez (ttx)