1:48 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2020-07-24 13:20, Maciej Delmanowski wrote:
Meaningful contributions are expensive. You need to set up a
development
environment if you want to write a proper role, test everything, write
documentation, fix all linting issues, etc. I've heard about many cases of
people that use DebOps and a few custom roles added on top of it. The
custom roles are barebones just to make things work your environment, and
they are left in a barebones state because they work for them.
Overcoming the above hurdle is really hard; some people even ask me to
write the roles properly from scratch which I'm happy to do, although they
either have to wait, or I have to drop whatever I'm currently working on to
do their thing. And then something else comes along that requires
attention, either in te project or at th workplace, and I'm distracted yet
again. I guess that's the life of a system administrator for you.
I proposed a "workaround" for this. Publish all the barebone roles (PR for
example). When someone else starts using it, they will – potentially –
naturally write some documentation and improve it.
For the issue and pull request labels, I went with a system
described
here[2], you might want to check it out. I wouldn't say that low priority
is synonymous with a good first issue... First issues can be spelling
mistakes, a missing comma, wrong number of empty lines in
'defaults/main.yml' between variables, something that's obvious to see in
the code you browse at the moment.
Just to mention it. There is a tool assistant way to fix most of that stuff in
defaults/main.yml in an automated way. https://github.com/ypid/yaml4rst
It should be integrated into DebOps. All of the heavy lifting is done. It just
needs to be updated and integrated. I would rather see that happen than having
people do this kind of repetitive work.
I would say, forget about it. The separate keyring repository was
created
to coordinate access to hundreds of various role repositories in the
'debops' GitHub organization. With the move to a single monorepo, keeping
your own fork in which you can work on separate branches and do pull
requests from them became trivial, so there's no need to track the GPG keys
of coontributors.
I guess when the CREDITS file gets added, when can specify the GPG
fingerprints of people in it and it will be enough to gather the keys via a
script. And we will have a proper source of truth for that as well.
Fair enough. I guess the keyring is pretty complicated. Some parts of it’s
validation should survive this transition though. Also it defined the roles.
Yup, it would be nice to set one up eventually, maybe when enough
people
declare that they would back it financially.. I don't really have time or
resources to do that at the moment though. But moving out from a single
work environment to focus entirely on writing shared infrastructure used by
other organizations would be an interesting job. Less stress from dealing
with daily issues of empty mailboxes, full disk drives, user calls, etc.
Basically a Tier 4 - infrastructure research and development[3] for
multiple organizations.
Agreed.
- --
Live long and prosper
Robin `ypid` Schneider -- https://me.ypid.de/
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE7eE3HRuH0o2l6AUVhv2YC78aQPgFAl8ayqUACgkQhv2YC78a
QPiv3BAAzdEmVIRAOymuus3KK8UDRc3cbJM9jd1PJf83jB2TOVt+6Pv6IB84pAmE
uolO4/dqMqKfAHI/6J4r4DXpsTK41jfsKOhEGBfI6haS1ca7InnzkTWrCVyKmokp
uDmZr8Ua7OwuApbACQ3WmgzZTD8gWrUjMrgnCBO3t3IZcQ6pRw0bg4qjDkj+t76y
N798Zx2rhNNlaHhxgSy9/IurCFa/H7NWWK5M0K8OrRkA+eSAIr2w7VZ5+sXXLQOF
zqUutx09p2q8qqDAzRKl/Nv7BRRgToEyhFH7Q4acUccT3f2WscENf8aofXVWATIm
2tSYxnEE84Nx2O8y0tuCW6ZP8Bnosp/aisCw53a4a6VbfZEFx4rZC3pNQbFc19qr
xsPdAhsuFKlneGvVZeRywNQA2kH4fdVMNceHlApNStEQYHIDWGw2FDFRe4tB/mFk
lXUYWeHAEzkCDcI2XR4DHrBu/G1nrVx/+isB0UN5bnOF8qnTAgfQzhZp3bi6QhJB
sKlqvvExZs6/fC6xzV6yfC4lCLA58MTHKMsijxEpxSX7DDx4z9fbDwBFtGbyX2c9
9eiBNhI7fYlUnaDB1mg2DdsfNUsAfgSlYCKhG/4L69OTX6yiSZ0xQUNliHlLRrLT
I88bg6B+Jvzz2XnAbyjXZtA+T7cpUwYjQrlzG+N936MQNzOv1ec=
=68HH
-----END PGP SIGNATURE-----