[arch-dev-public] A contrib repository

[Sven-Hendrik Haase]

On Thu, 14 Mar 2019 at 01:05, Gaetan Bisson via arch-dev-public <
arch-dev-public at archlinux.org> 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.