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