On Thu, 14 Mar 2019 at 01:05, Gaetan Bisson via arch-dev-public < arch-dev-public@archlinux.org> wrote:
There is a *lot* of small tools people have written over the years that resides in bin/ directories which could be useful for more people. We also have several such tools on soyuz, where sogrep was added to devtools this week.
I have been thinking it could be great to have a simple `contrib` repository where every team member has commit access. This could work as a staging area for tools we would like to promote to `devtools` later on.
We could maybe sort this into directories for its purpose: * packaging * security * devops * testing * bugwrangler * misc
Tools that can be added here is the `ch` scripts from Bluewind, and the
tools eli has created. I also have some tools to look for pkgname in archweb, check them out from svn and check them against a nvchecker file.
This would hopefully give us a space where we can experiment with new
tools in a collaborative manner. I'd love to hear some feedback or
[2019-03-13 23:46:10 +0100] Morten Linderud via arch-dev-public: pkg-* maintainer thoughs on
this!
I think it's a great idea but it needs a solid maintainer. Without a clear leader it's (probably) going to be a free for all and we'll drown under bikeshedding issues within a month. But of course that doesn't mean we'd lose anything trying anyhow.
I also really like the idea but I think we could have a bunch of maintainers and have everybody else just make PRs. However, then it would be kind of like the devtools repo I suppose. We should decide exactly how this repo would be different from devtools. If both of them necessitate high-quality submissions with a PR-only system, I see them overlapping. We can resolve this in two ways: 1. Not have an extra repo but strongly encourage PRs against devtools with new tools. 2. Open-for-all devtools-contrib repo as originally suggested by Morten. I actually prefer 2. as this encourages openly sharing even half-baked scripts. This sets a lower barrier for entry and good tools with good documentation could still be promoted to be part of devtools.
Among other things, I'd personally like to see the repo maintainer enforce sensible and consistent naming for the tools, preferring longer, explicit names over shorter ones. For instance, I'm sure many of us have one-letter scripts and if we contribute them all there's bound to be collisions along with the problem of not knowing at first glance what each tool does. We could maintain a bash alias file containing everyone's favorite nickname for each tool.
I see your concerns and I'm not sure we should even try to address these for what is meant to be a heap of random useful tools. I think there is a lot of value in collecting the tools. I think about it a little bit like AUR where the low barrier of entry makes everybody just throw stuff out there and then the best tools are promoted.