On Thu, 14 Mar 2019 at 01:05, Gaetan Bisson via arch-dev-public < [email protected]> wrote:
> [2019-03-13 23:46:10 +0100] Morten Linderud via arch-dev-public: > > 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 > pkg-* > > 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 > maintainer > > tools in a collaborative manner. I'd love to hear some feedback or > 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.
