On 3/14/19 8:46 AM, Morten Linderud via arch-dev-public 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 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 was fairly sure any user can create a git repo on our server. Look at "Developer Projects" on https://git.archlinux.org/ . Or use github, where some of these scripts are already located. I don't see the need for another repository. A

[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. 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. My two cents. -- Gaetan

On Thu, Mar 14, 2019 at 09:14:22AM +0100, Christian Hesse wrote:

Morten Linderud via arch-dev-public on Thu, 2019/03/14 01:02:

...

This is why we have talked about adding gitolite to host these repositories

I've wanted to propose this a long time ago...

In fact you can give every user full access to it own area in every repository, while important branches are still protected. I have several git servers that use something like this:

repo devtools RW+ = admin RW+ personal/USER/ general/ = @all RW master$ develop$ refs/tags/ = @devtools R = @all

-> admin can do everything -> random user 'foo' can do everything in personal/foo/ and general/ -> random user 'bar' can do everything in personal/bar/ and general/ -> members of group 'devtools' can push to master and develop and push tags, but forced push is denied -> random (authenticated) user can read everything

Yep! Here is the proposed patch set compared to an outdated master branch: https://github.com/Foxboron/infrastructure/compare/foxboron/git It was put on hold as there is a cgit vs gitlab dicussion in relation to the svn->git migration. But lets not derail the `contrib` repo discussion :) -- Morten Linderud PGP: 9C02FF419FECBE16

...

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.

+1 here. Without a solid maintainer keeping things in check and helping order things around (e.g., how are these scripts going to be distributed) things will be somewhat hard to be useful.

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 agree with this. I'd also like to add that it'd be nice to have (even if just philosophically) the goal of having contrib/ scripts being promoted to devtools or somewhere else. Thanks, -Santiago.

On Mon, Mar 18, 2019, 04:31 Morten Linderud via arch-dev-public mailto:arch-dev-public@archlinux.org> wrote: On Wed, Mar 13, 2019 at 02:05:47PM -1000, Gaetan Bisson via arch-dev-public wrote: > 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. > > 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. If we want someone to a dedicated maintainer, I can probably do so. But I believe that we can give everyone commit access, block commits to master and just enforce a system where two reviews are needed before merge. I really don't think more is needed, but as noted; I can probably take some responsibilities if the devs think that is warranted. When it comes to packaging and naming conflicts, I wonder if it's just easier to drop all the supplied files into `/usr/share/archcontrib` or something. Makes it easier to package and doesn't clutter anyone's PATH with a lot of (sometimes) unneeded tools. -- Morten Linderud PGP: 9C02FF419FECBE16 -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEktnGzemaICTWkKdu50JoO6CMsv8FAlyOvK0ACgkQ50JoO6CM sv8lBQ//aoNFKxUDM4Qcpi6nXXDDw51loxJp4AB+SYTv/Vml5tag7fVAkniUphLD ujJYY8/sSVqke29YYpG+OyJIIp91jP7WJ6nwtRVY2lsfOOUGkEX3HKEN0NCHxe9/ GpQHn1GqZAp3+FjSwxvJabpm+aGDL4CLVErdbiDKocpZJf61WSAXNHpGPj26PzUm L+fIkPDu8SEqENBVVkC9cKnf2+oInQ2ECHknSN/lBbNbwh2z2kAW46kglJXryJcE jO2gYt9kzU6NqcfKwHXHY0XCQd0H0pVMjfaK6PB1N+dwbgHAAbyhV/SIziFEP9kc PDK5NAFAcgQI+999Q9T0nufc+lqvPn9MuQ89OPINQhwTGCxEkUlicVrBYY/9ZFhC rrsTp7LExeBsMhAE6havnv2UHgkJH9ttv3FmSi81HsUYsgrxsUXpijqZUSacra5l 4VEGR9pPjsdERco2UZo9hcneLutQn0T2mCVLgIiCdjS2ZjsQuuHZ5RNBkyeNnWOC lBOBq7lddxhIiWGAjz60KOox5KL68OYlY4mZXbMQ2x2n3v2XF5VVL/ncp9F9CFo4 J6JGjab38LEemMnOFBgFS2XkRMmV7G+siD1++VdEKSCoy2tICPm5SAQiG9Ueo48y nUMD2+gfkzFNJmVQdym9YVxAKlbLWDGVHGd9/a43ZzjKKIReJgk= =y2os -----END PGP SIGNATURE----- So shall we progress with this? I don't think we can lose anything by just trying it out. Let's put up a GitHub repo and get coding. Of course it should be mirrored to our infra.

On Thu, Mar 21, 2019 at 06:58:56PM -0400, Santiago Torres-Arias via arch-dev-public wrote:

Morten, why don't you start a repository on GitHub and we start figuring things out while things move.

Moving github repos between organization and user is a hassle, so would prefer if a dev could create a repo and provide access on github at least.

I'm also more than happy helping with maintenance work, although I don't think I have enough time for being the only maintainer of this.

Yasss! +1 -- Morten Linderud PGP: 9C02FF419FECBE16

On Wed, Mar 27, 2019 at 11:14:17PM +0100, Morten Linderud via arch-dev-public wrote:

Going to try figure out the packaging bit through the weekend.

And one long weekend later and we have "archlinux-contrib" in [community]! There are currently a few scripts available. - checkservices Originally writen by seblu, and commited to contrib by Giancarlo, it checks which services needs to be restarted after packages have been updated. - co-maintainers It queries archweb and helps you figure out which of your packages has how many co-maintainers. It's useful in the case where you are going on vacation and want to produce a list of packages which currently only has you as the maintainer. - review Helps you download PKGBUILDs from an AUR maintainer. This is useful if you want to review TU candidates. - compose-asa Aids security team members composing the advisory email locally. - security-tracker-check Checks stdin for CVEs and cross-checks with our security tracker if they have been added or not. Useful if you are looking over oss-security emails :) svenstaro also wrote a `offline-build` tool that went into contrib. Eli polished it and moved it to devtools after some work. Jelle also has a pull-request working on "repo-sec-checker" checks if there are binaries in a package/repo which does not have the appropriate security hardening applied. It should be noted that all of this is currently being packaged to `/usr/share/archlinux/contrib` as it seems like an better idea to not clutter peoples paths with misc tools. I'll be super happy if people contribute other misc scripts, and everyone that wishes will be added to the github org and can handle pull-requests. -- Morten Linderud PGP: 9C02FF419FECBE16