-----BEGIN PGP SIGNED MESSAGE-----
On 2020-07-24 13:20, Maciej Delmanowski wrote:
Meaningful contributions are expensive. You need to set up a
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
here, 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
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
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
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 for
Live long and prosper
Robin `ypid` Schneider -- https://me.ypid.de/
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----