12:26 a.m.
Hello everyone,
During today's online meeting via Jitsi, we talked a bit about how DebOps is
currently developed, how this might change in the future and what are possible
scenarios for the project. Two models were discussed, one where there's much
more maintainers and contributors involved in the development with much larger
scope, and a second one where project stays tightly focused on a small set of
features with fewer contributors. I think that this warrants further
discussion on the mailing list, since many people are using DebOps in
production environments and I imagine that they wouldn't want to see suprises
there.
Going a bit backwards, current release model and schedule is described
here[1], and if you haven't seen that yet, the development worklow which I'm
using at the moment is described in the documentation as well[2]. What is left
out (I think) is how the actual code is developed and where does it come from.
I usually include a report of the number of contributions with each new
release, and you can see a monthly progress on GitHub insights page[3]. At
present the project is developed mostly by me and a few other people active in
any given month, and there's usually a long tail of one or two changes per
person. The changes get into the project via GitHub pull requests, and after
a review usually by me, I pull them to my local repository and merge to the
'master' branch when they are accepted. At the current size of the project it
seems that this is enough.
Is that a good governance model for DebOps? I suppose, it seems that it works
out well so far. In this model I get the last word about what gets in and what
doesn't, but on the other hand there's a backlog of proposed changes that need
to be reviewed and accepted which takes time, so it's currently slow. DebOps
is at the moment developed by volunteers in their free time - some of that
time is of course during their normal work hours if DebOps is used at work.
With more and more contributors providing patches that will probably have to
change, otherwise the pace of development will grind to a halt.
There are two solutions we discussed a bit during the meeting. When the
current codebase and its scope is too large, we could essentially split the
project into smaller subprojects with each one being maintained by a person or
a group of people who then try and combine everything into a whole. This is
a model used by OpenStack and can probably be used effectively when each
subproject is backed by a company and has dedicated team behind it. On the
other hand we had a similar situation in the past, where each role was
developed in a separate 'git' repository which increased the maintenance
burden when changes had to be synchronized everywhere. That's why switch to
the monorepo happened.
Another way is to use the model used by the Linux kernel developers, where
there are essentially "layers" of contributors that create changes and push
them to maintainers of subsystems which after review push them to Linus to
merge in his official kernel. If you're interested, the whole process was
nicely explained by Greg Kroah-Hartman in his 2016 presentation about the
topic[4].
Both models assume that a large number of people participate in the project,
so at the moment we don't have to worry about which path to take. But I think
that the model used by the kernel developers fits better for a project such as
DebOps, which is developed in the open, shared space by a dedicated community.
Use of 'git' as the version control system also gives us an advantage here
- since the project is maintained in a monorepo, we can leverage the mechanism
of codeowners[5] to give interested people "ownership' of parts of the code.
In such case they would take over reviews and maintenance of selected parts of
the codebase. That file is currently present in the DebOps monorepo[6] but is
not really used for anything - I'm keeping track on all changes and nobody so
far volunteered to help with reviews of a specific role or part of the
codebase, at least since that mechanism was added. If you want to be included
to easily keep track of parts of the repository that interest you, let me
know. In such case I'll wait with merging a given pull request for your
review.
Another closely related topic are the git commits themselves. At the moment,
with relatively small number of contributions, I accept the git commits as-is,
with close examination for any security issues. But if number of contributors
increases ten-fold, this will become an attack vector - remember that DebOps
code is executed with root privileges on a large and distributed
infrastructure - very interesting target indeed... In such case, the commits
will have to be cleaner to meet approval.
At the moment in our contributor workflow[7] we mandate use of GPG signatures
in git commits and advocate for clean and concise git commit messages[8], but
that's rarely enfoorced. The output of 'git log -p --no-merges' leaves a lot
to be desired in the context of easily readable and clean commits, and I'm
guilty of it as well - partially because I'm trying to record changes in the
official Changelog file and I don't want to simply repeat the note from the
Changelog in the commit message. So now I wonder, if a better focus on cleaner
git commits in lieu of less verbose Changelog file would work better in the
long run? How many of you rely on the Changelog to keep track of important
changes (the upgrade notes are of course another matter and should stay as
they are)?
As for refactoring badly done commits, this can be done but refactoring
overrides the GPG signatures... So maybe we should only care about them on the
"intake" instead, for example on the GitHub pull request page, and when the
code is pulled and being prepared for merge to the 'master' branch, I could
freely refactor and fix up the commits when necessary? The original GPG
signatures will be goned by this point, but authorship of the code will
remain. In such case we coould also stop using non-ff merges which create
a separate signed merge commit to mark acceptance of code, and the resulting
commit history would look a bit better without the need for '--no-merges'.
Or alternatively, should I point out all the issues in the pull request before
the pull, then the original authors could rework the patches, rebase where
necessary and provide a set of clean commits? To be honest that seems a bit
imposing to me, but if more and more people are relying on my judgement about
what gets into the codebase, perhaps my standards need to be higher?
Let me know what you think,
Maciej
[1]: https://docs.debops.org/en/master/news/releases.html
[2]: https://docs.debops.org/en/master/developer-guide/development-model.html
[3]: https://github.com/debops/debops/pulse/monthly
[4]: https://www.youtube.com/watch?v=vyenmLqJQjs
[5]:
https://docs.github.com/en/github/creating-cloning-and-archiving-reposito...
[6]: https://github.com/debops/debops/blob/master/CODEOWNERS
[7]: https://docs.debops.org/en/master/developer-guide/contribution-workflow.html
[8]: https://chris.beams.io/posts/git-commit/
12:52 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Here's my two cents
Another way is to use the model used by the Linux kernel developers,
where
there are essentially "layers" of contributors.
:) Contributors far as the eye can see!
I feel that with the current number of contributors, we're more likely to
see results by concentrating on what each person can offer than dreaming up
an
organization to last the ages.
The layers approach certainly applies to merging itself; I'm in no hurry to
see more people having that access.
The stakeholder model is pretty much what we organically have right now.
Like, me too, long term I will make sure stuff on my critical path, which
will
include up to web python stuff like django, is going to keep working;
plus I want to volunteer some work for the health of the project itself.
I think that a split between use-cases would be good to define _work
groups_,
like, `self-hosting` or `privacy` would be a meaningful way to group devs.
A benefit is that it would lower the bar for being "on top of" a specific
use
case: Knowing all of the `self-hosting` roles is enough to advocate for the
use-case and provide review and support to others.
In terms of actual roles, there's bound to be a ton of overlap.
Such a separation already exists in a way in the `site` playbook, at least
in
the ways that matter to implementation. I don't think this should leave a
footprint outside `CODEOWNERS` and maybe the doc.
Apart from stakeholder groups, which would exist unofficially anyway,
gruntwork
groups such as `doc` and `code-style` could offer opportunities for new devs
to make themselves useful and familiarize themselves with the project.
I have seen this kind of work successfully used as an onboarding tool in
Godot.
With the current arrangement it's just keeping Maciej from doing more
specialized work.
In practice any way we decide to split the work, Maciej will have to
oversee it
until he knows "reviewed by x" is good enough to merge.
Anyway, let's see some volunteers.
I'm posting a proposal on doc on a separate thread, so it doesn't take focus
away from this discussion; It has plenty to do with what we're talking about
here, though, so do check that as well.
GPG signatures on git
Frankly, @drybjed has the only signature that matters to the outside world.
I find it both fun and useful to sign our commits for internal verification,
but as an end user my trust is based on the signed merge.
I would think the contributors' sigs have fulfilled their purpose when they
reach @drybjed and a signed release tag by him might be all that's needed
on the
user side.
I'm mentioning this purely in the spirit of not letting it stand in the way
of
getting things done. As long as the actually useful functions of trust and
attribution do not break, it is there to serve development.
Okay I am replying to Maciej in third person for some reason :)
Give interested people 'ownership' of parts of the code.
I like codeowners. @ypid has a ton of stuff there too.
I think authors of roles should automatically go there and opt out later if
they choose. It would set an expectation for maintenance that I think
should go
together with the rest of the debops code standards.
I hear rumors of a _doc team_ gathering in the nearby woods...
Cleaner git commits in lieu of less verbose Changelog file
Users rely on the changelog. I guess it would be cute to autogenerate it
from
git and I really like the fact that it would enforce a style guideline, but
a
good commit message is not directed to the same _audience_.
Plus it would get full of cruft like "fixed typo in obscure_task", just
written
well.
Should I point out all the issues in the pull request before the
pull,
then
the original authors could rework the patches, rebase where necessary
and
provide a set of clean commits? To be honest that seems a bit imposing to
me.
You make the spec. It is all the rest of us have to go on.
Being up-to-spec with a project like debops is a net benefit to anyone
receiving your guidance. Learning is one of the core reasons people
volunteer
to contribute to free software. I was super happy when you made suggestions
on
my first PR and then let me fix it.
Now, having to say it twice instead of pointing at a doc is an issue.
Searching the issues and PRs themselves for this history on github can get
pretty messy too.
But do read my other thread.
Still here? Here's a link to an influential essay called "The Tyranny of
Structurelessness"[1] by American feminist Jo Freeman.
Non-required reading - just came to mind. :)
[1]: https://www.jofreeman.com/joreen/tyranny.htm
Tasos
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEXbaOHtREtFSBLXcdOXguVye2c7EFAl8Za94ACgkQOXguVye2
c7GVihAAmvP/HmEf3ppsc4/A4qYuGGCokgFHKjswdfVERqwaQKxlTT5Jve7uu612
oQHXuDYcRbmf5o/Th5pEuuIsWWDDB/W7F1jT4IKUkysYsDr6Rr4yzrTJnXjjA+Rf
875FAMweotemS8xR5RW8nY4TlBFR/x1mcre3tm4KD5cmCm/3EbkC43Bpf6to7X35
JXc3QhpDXQeke60AjKCXgh/8nzmDUrLHkmZGY2XWddbtPDhMJi5Hv4PXEwAURG7I
W9Tj+r+kA1K6iEsm5MNBENWic5wg2LYOpIuqzQ3ymAgiXtbLgdM1eRnWRgUf+bim
Nb4Q7lLcv5u0QEdZVg8H67nmv0f1nU/OYY7OJYaLlwbViWxdIUYY1D8FhamKYyfq
YxPEG+9wFzLSr+T8Jipeq3J7DQxBV7jn/aBydzFDEHiOYcRcqa1JSk8Hh9XC1jd6
evpdastSxh0/kHU4qy7fX0EgXrhbna0aYJVS5Dq+VlTVb2aVFiK0S+5gVtZzksS9
cRpOXQ8irwIYTG7CxwSFwqDMF/dj/2mg6WSJiM/oYD09XxAGXOSyojeTMJmb5bRp
QCjkg7tBDdeg/dLXEjKtvehHkezbK6XoqJu7NtJK1ITewwMK/YZsEov3Noge6zeV
FOO3YEn79/cCpxi32Du/6C1Js4rsALrG2pOX8iK8tvfH4rggceY=
=tcpa
-----END PGP SIGNATURE-----
2:12 p.m.
On lip 23, Tasos Alvas wrote:
I feel that with the current number of contributors, we're more
likely to
see results by concentrating on what each person can offer than dreaming up
an organization to last the ages.
The layers approach certainly applies to merging itself; I'm in no hurry to
see more people having that access.
The stakeholder model is pretty much what we organically have right now.
So that means the current project structure and stuff we're doing is fine
as-is for now? I can go with that, let's see where it will be in a few years,
then we can reevaluate when necessary, or when people start complaining.
In terms of actual roles, there's bound to be a ton of overlap.
Such a separation already exists in a way in the `site` playbook, at least
in
the ways that matter to implementation. I don't think this should leave a
footprint outside `CODEOWNERS` and maybe the doc.
Apart from stakeholder groups, which would exist unofficially anyway,
gruntwork groups such as `doc` and `code-style` could offer opportunities
for new devs to make themselves useful and familiarize themselves with the
project. I have seen this kind of work successfully used as an onboarding
tool in Godot.
Currently the codeowners file uses "teams" for such purpose, but these teams
are defined on GitHub which I don't necessarily like - this makes the monorepo
bound too much to GitHub itself which I would prefer to avoid. I think what we
can do is define these groups in the comment section of the codeowners file,
then people in each section can be added to the apropriate file patterns such
as roles. Of course more than one person can be marked as a codeowner, so we
can definitely have a diverse overlap.
I wonder if something similar to the CREDITS file[1] should also be in the
repository? Copyright lines required in each file kind of inform who is the
author of a given file, but maybe some more details about each person involved
would help strenghten the community a bit? I don't really care about people's
home addresses (also, GDPR nightmare), just some info where everybody works
and what their interests are should be interesting. Should I set it up?
[1]: https://github.com/torvalds/linux/blob/master/CREDITS
> GPG signatures on git
Frankly, @drybjed has the only signature that matters to the outside world.
I find it both fun and useful to sign our commits for internal verification,
but as an end user my trust is based on the signed merge.
I would think the contributors' sigs have fulfilled their purpose when they
reach @drybjed and a signed release tag by him might be all that's needed on
the user side.
I'm mentioning this purely in the spirit of not letting it stand in the way
of getting things done. As long as the actually useful functions of trust
and attribution do not break, it is there to serve development.
I see... True, I guess after the commit is merged, only the signature of the
merge matters. So I guess it's fine if I override somebody else's GPG
signature with mine as long as their authorship information stays in the
commit. This has been happening already with commits that are cherry-picked to
stable releases, but that couldn't be helped - they were new commits, not
something merged via another commit.
> Give interested people 'ownership' of parts of the
code.
I think authors of roles should automatically go there and opt out later if
they choose. It would set an expectation for maintenance that I think should
go together with the rest of the debops code standards.
Sounds like a good idea. This probably should be mentioned in the contributor
guide, just have it clearly visible. if somebody doesn't do it, I'll try to
add them manually as a codeowner of a role, that way they will at least be
notified by GitHub when somebody messes with their code.
As for accepting merges - when I see changes in parts I'm not familiar with
I always try and reach out for the role authors when they are around.
I suppose that this would have to be with a timeout in case that people are no
longer interested in DebOps for various reasons.
> Cleaner git commits in lieu of less verbose Changelog file
Users rely on the changelog. I guess it would be cute to autogenerate it
from git and I really like the fact that it would enforce a style guideline,
but a good commit message is not directed to the same _audience_.
Plus it would get full of cruft like "fixed typo in obscure_task", just
written well.
Agreed, that's why keepachangelog.com project discourages doing that and
promotes more personalized Changelogs. I guess it will have to stay then, at
least for now.
> Should I point out all the issues in the pull request before the
pull,
> then the original authors could rework the patches, rebase where necessary
> and provide a set of clean commits? To be honest that seems a bit imposing
> to me.
You make the spec. It is all the rest of us have to go on.
Being up-to-spec with a project like debops is a net benefit to anyone
receiving your guidance. Learning is one of the core reasons people
volunteer to contribute to free software. I was super happy when you made
suggestions on my first PR and then let me fix it.
I will do more through reviews with suggestions then.
Now, having to say it twice instead of pointing at a doc is an
issue.
Searching the issues and PRs themselves for this history on github can get
pretty messy too.
I think that documenting the specification is not enough, nobody reads the
user manual. We need to add custom rules for the existing linters like
ansible-lint, that should help enforce code structure automatically even
before it gets committed to the repository. Passing through the linter should
be say, 80% chance that your code gets accepted. Debian has Lintian which is
a huge help th the contributors, using a similar approach in DebOps should be
good for us as well.
-- Maciej
7:08 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2020-07-23 14:12, Maciej Delmanowski wrote:
Use of 'git' as the version control system also gives us an
advantage here
- since the project is maintained in a monorepo, we can leverage the
mechanism of codeowners[5] to give interested people "ownership' of parts
of the code. In such case they would take over reviews and maintenance of
selected parts of the codebase. That file is currently present in the
DebOps monorepo[6] but is not really used for anything - I'm keeping track
on all changes and nobody so far volunteered to help with reviews of a
specific role or part of the codebase, at least since that mechanism was
added. If you want to be included to easily keep track of parts of the
repository that interest you, let me know. In such case I'll wait with
merging a given pull request for your review.
I guess it makes sense when changes to roles I wrote require my explicit
approval from now on. I review all those changes anyway. So please wait with
merging. I might take a few days until I can review PRs. I will now keep the
codeowners file updated as well to reflect that.
One role I am not the best person to maintain is Apache. I am not actively
using it but there have been contributors in the past. I would be happy to
pass this one on to someone actively using it.
In the past, we had this. I took the lead on
https://github.com/debops/ansible-owncloud and maintained it. This was
possible because I used it at work. Now things are different and also my
operational security increased so I cannot dedicate more spare time to do this
as before.
My hope would be that people who use DebOps at work can get more involved.
So for now, please wait for my approval, but no need to overdo it. When a
commit touches all the roles for some style fix, you don’t need to wait for me.
This is does not really put more pressure on me.
So that means the current project structure and stuff we're doing
is fine
as-is for now? I can go with that, let's see where it will be in a few
years, then we can reevaluate when necessary, or when people start
complaining.
Maciej was planning ahead :) I like the idea of making more use of the
codeowners file and working groups.
At the moment in our contributor workflow[7] we mandate use of GPG
signatures in git commits and advocate for clean and concise git commit
messages[8], but that's rarely enfoorced. The output of 'git log -p
--no-merges' leaves a lot to be desired in the context of easily readable
and clean commits, and I'm guilty of it as well - partially because I'm
trying to record changes in the official Changelog file and I don't want
to simply repeat the note from the Changelog in the commit message. So now
I wonder, if a better focus on cleaner git commits in lieu of less verbose
Changelog file would work better in the long run? How many of you rely on
the Changelog to keep track of important changes (the upgrade notes are of
course another matter and should stay as they are)?
My usual update workflow is like this:
* git pull --verify-signatures --recurse-submodules=on-demand
* git diff HEAD@{1}..HEAD
* Drill into individual git commits (and read their message) as needed
So the changelog is really nice to learn what I am about to review. I don’t
read all the commit messages.
Bad git commit messages should not be merged and instead be reworked by the
author. I don’t really see the need to rework commits after they are merged.
History is history. When you change them post merging it would also decrease
the learning effect. As long as the PR is not a critical bug fix, there is no
pressure for bad quality being merged. So as long as there is
something wrong with a PR, just leave it open. People interested will
eventually find and work together to get it ready. The most scare people in a
project are the maintainers. So I would just point out bad commits, give a
hint and wait for it getting fixed.
I see... True, I guess after the commit is merged, only the signature
of
the merge matters. So I guess it's fine if I override somebody else's GPG
signature with mine as long as their authorship information stays in the
commit. This has been happening already with commits that are
cherry-picked to stable releases, but that couldn't be helped - they were
new commits, not something merged via another commit.
I guess this depends on person to person. Maybe lets make the cut like this:
If someone is in the https://github.com/debops/debops-keyring, they probably
care enough for their signatures not to be altered in the master branch
(cherry-picking is fine of course).
Please tell me if there is something wrong with my messages and I will rebase
before it gets merged.
I think what we can do is define these groups in the comment section
of
the codeowners file, then people in each section can be added to the
apropriate file patterns such as roles. Of course more than one person can
be marked as a codeowner, so we can definitely have a diverse overlap.
This would also define an interface for how to define who is member of such
teams. I like the idea.
I wonder if something similar to the CREDITS file[1] should also be
in the
repository? Copyright lines required in each file kind of inform who is the
author of a given file, but maybe some more details about each person
involved would help strenghten the community a bit? I don't really care
about people's home addresses (also, GDPR nightmare), just some info where
everybody works and what their interests are should be interesting. Should
I set it up?
Sounds like an idea. Just don’t make the description too long ;-) Because I
like examples, here is what you may include about me:
N: Robin `ypid` Schneider
W: https://me.ypid.de/
D: Self-hosting with focus on Free Software, security, cryptography and privacy.
D: IT System Engineer at https://www.geberit.com. No DebOps. SaltStack for SLES.
S: Baden-Württemberg, Germany
- --
Live long and prosper
Robin `ypid` Schneider -- https://me.ypid.de/
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE7eE3HRuH0o2l6AUVhv2YC78aQPgFAl8ZxAsACgkQhv2YC78a
QPg0Dg/+OTgjzzkI2KWAfX4XKVPW7zeyUUA3O5BVBw7Sccy7x4tJovfbBN5TeneY
vPLp5nSMjtOhAqlYkKdq1fK5YDVsrOc4r5Q5Pbfc4EQZMCB3+u8yJaZz0bJIvt2i
Iw4nZ3UyK8TD9R9RYq1ccyEMEaHmEa9EbUD65kCC3VJmS6NDokBwcljlBlBZy4t6
i2FBVoaPugsVXstgDRy8EFn7YFEaDZiLED0W+e6KKskaunFM7Zas8ICCCYBm4z6r
HStkNanFdLFE7vL0PoD14+M300KzRB6jl9q0m0exy3ioFZMOns90JXHMYfIrfW3K
pPAgHST784vRelyFPWP8VPsrvgz3wc3Y0k3nHPjcA7Bn6uZuM777nEXEPf8eN8NO
xqV+RYgEwwCzlHnXu/3eNi6rJX2hcmHyGSlxESS5nttDidm0esZtAUSV7ksQA4AP
IbKxhkQ2hBik6wTGvum6Lk2IZ/3SPhD+AdHZ7pj6fs2IrAzI92bSqJM14nnW9NT8
FbODr5qEC49TS8++REhJK6XNMl3PN2mUmHcW7M9Dv53wSNnA56hWQNDuMfQwVcLQ
HcqMDfQssy8sq2rsX4mV/yMC1XTvTgJ+vOZ0xHPKJ4AVFFPYsenBwQKFf3RiDCj+
wYjoGAKnRWFF6uPR/FdNEBRHx23xp44gNlB/u0Bu+zBIOQlAE+M=
=BfQB
-----END PGP SIGNATURE-----
12:10 a.m.
On lip 23, Robin Schneider wrote:
I guess it makes sense when changes to roles I wrote require my
explicit
approval from now on. I review all those changes anyway. So please wait with
merging. I might take a few days until I can review PRs. I will now keep the
codeowners file updated as well to reflect that.
I think that I can wait a week for a good PR to be reviewed by dedicated
people. if you want longer, post a comment in the PR so I know you plan to do
a review.
One role I am not the best person to maintain is Apache. I am not
actively
using it but there have been contributors in the past. I would be happy to
pass this one on to someone actively using it.
Sure. I'm updating the CODEOWNERS file so I'll remove you from apache
reviewers.
My hope would be that people who use DebOps at work can get more
involved.
Perhaps now that there will be a dedicated place to handle these things, more
people will be interested in participating.
So for now, please wait for my approval, but no need to overdo it.
When a
commit touches all the roles for some style fix, you don’t need to wait for me.
Will do.
> So that means the current project structure and stuff we're
doing is fine
> as-is for now? I can go with that, let's see where it will be in a few
> years, then we can reevaluate when necessary, or when people start
> complaining.
Maciej was planning ahead :) I like the idea of making more use of the
codeowners file and working groups.
The thing is, over the 7 years of this project's lifetime it was completely
overhauled twice - once to split a monorepo into separate git repositories,
and then after a year or so, to merge everything back. That happened because
I didn't really plan ahead far enough. It was costly, both in time and
additional overhead of developing tooling around the project to handle
changes. I would not want to make a similar mistake that would have to be
reversed again in the future, so exploring possibilities seems reasonable.
Bad git commit messages should not be merged and instead be reworked
by the
author. I don’t really see the need to rework commits after they are merged.
History is history. When you change them post merging it would also decrease
the learning effect. As long as the PR is not a critical bug fix, there is no
pressure for bad quality being merged. So as long as there is
something wrong with a PR, just leave it open. People interested will
eventually find and work together to get it ready. The most scare people in a
project are the maintainers. So I would just point out bad commits, give a
hint and wait for it getting fixed.
Sure, I'll try to do that. Alternatively, I can just get a PR that is good but
has a few flaws and fix it myself. :-)
I guess this depends on person to person. Maybe lets make the cut
like this:
If someone is in the https://github.com/debops/debops-keyring, they probably
care enough for their signatures not to be altered in the master branch
(cherry-picking is fine of course).
I think that there's no need to be picky here. If the commits are signed by
personal keys, I'll try to preserve them if possible. If they are signed by
the GitHub key (done via web editor), they can probably be overwritten and
treated as unsigned commits.
Sounds like an idea. Just don’t make the description too long ;-)
Because I
like examples, here is what you may include about me:
N: Robin `ypid` Schneider
W: https://me.ypid.de/
D: Self-hosting with focus on Free Software, security, cryptography and privacy.
D: IT System Engineer at https://www.geberit.com. No DebOps. SaltStack for SLES.
S: Baden-Württemberg, Germany
Will do. Although I will probably go with RFC822 format commonly used in
Debian, so with more expressive header names.
-- Maciej
8:32 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hey,
Ooops, I admired y'all sticking to the character limit, but then I went and
did 80 instead of 78... The horror! I was crafting those mails for hours.
Heh, I was worrying if I was coming on too strong, mostly due to editing
out "I think" statements that were all around my first draft. I probably
was.
I shall prefix all my stuff with:
The words "MUST", "SHALL", etc are NOT according to RFC2119.
> The stakeholder model is pretty much what we organically have
right now.
So that means the current project structure and stuff we're doing
is fine
as-is for now?
No, there are real challenges. I was just stating that they are better
viewed
through the lens of what we have right now and applying incremental changes.
I think it is the nature of the project to invite highly specific additions
but to need conscious organization for long-term stuff, like maintenance.
I don't mean to restrict the conversation to my own point, but the way I see
it the challenge at hand would be project health. Our goals, something like:
* Take stock of existing people an empower them to contribute
* Make room in the processes for the community to take over
* Lower the skill bar for meaningful contributions
A goal I would find fair for you particularly, would be to be able to bundle
tasks that don't need your overall understanding of the project so you can
focus on tasks others can't do and probably have more fun working at.
The use-case workgroups are a good start, I think, even as empty concepts at
this point. They do represent something real about each community member.
Maybe we should brainstorm these categories and a list of roles to go with
each, and have those as additional role index flavors. On an issue then I
can wrap it up. Probably based off the existing tags in github.
I'm not sure I like the name "workgroup" for something that clearly means
use-case, I only like that it's clearly talking about _people_.
Tribes? lol.
Tagging issues for each of the tribes would be a good indicator for people
to swoop in and solve a problem in their domain.
The responsibility for each of them would be a different hat that you can
eventually hand over to other people, already there for them to claim.
It might be even more sellable for people using debops at work to justify
contributing to plumbing that they really depend on.
Timing should also be probably taken into account, leaving slack for the
community during the first months of a release cycle then wiping the low
priority stuff nobody picked up. As the community grows maybe we make an
event out of it.
There should also be a tag for `easy`. Like with that missing newline that's
hanging on the issue queue right now. Just with a name that will not startle
the issue submitter.
Ah, actually github proposes `good first issue`. Hopefully contribs will do
a second one after that. :)
I suppose `good first issue` also implies `priority:low`?
Imre has contributed some solid Project Manager work already, I bet he will
also have some informed opinions on this matter.
Oooh I had missed that.
Organizationally though, I mean, you care about it as a dev, and use it to
verify project health, not to trust a release.
git
+1 for "history is history".
I'm no authority; I've been using git for a while, but the most advanced
stuff I'm familiar with is the rebases I've had to do for here. :)
CREDITS
It seems like an ok format, flexible enough.
Yeah I'm not married to github, either.
I guess an email to reach each contributor is enough to reconstruct the
community outside github. I'm not sure if requiring publishing one's mail on
the repo and packages is a good idea, though. LDAP on the debops infra? ;)
GDPR-wise, it's clear that this information is intended for publication
under
GPL. It should be removed if requested, but that's just human decency. :)
It's good to have tech solutions, but I think the matter at hand is more
about people.
nobody reads the user manual.
SIR, I SHALL ASK YOU TO STEP OUTSIDE!!1 ;) ~style-force
So, I had a similar paragraph on my doc team mail but I edited it out as I
thought I was pontificating (I was). But here goes.
People read as much of the manual as they can take, often from the
beginning:
* When grabbing their first loose role from galaxy
* When first using debops
* When integrating their first private role into debops
* Before contributing their first minor fix
* Before contributing their first debops role
* Before contributing their first improvement to the project as a whole
There's no fancy brochure website so we add management who are evaluating
debops to use on their admins. :)
After that, if they choose to follow the manual, it's probably more
manageable to follow the `[doc]` commits than to reread the whole thing.
Now these people have had a go at the manual for 1 up to 6 times.
Sure, people who have already done it a few times might skip a few steps.
People after that final point mostly just revisit the reference sections,
and those are handled pretty well by the automated solutions already in
place. Style guides are certainly a reference one would keep open.
The current sections offer a structure to accommodate speaking to users
depending on their current task and, say, "minimum required hardcore level".
This can inform cohort goals, such as "no need to dig into debops source to
implement your role against debops". It's also a milestone from many users,
and sometimes your project isn't even the one they'll cross it on.
Note to self: a short guide about `ack`ing the source. ;)
Also, I or anybody willing can point people to the manual, containing some
answer you gave days ago. Hell, it the first debops meet someone recited
like 5 minutes out of the ansible manual. No redhat dev involved. :p
Anyway, back to the list. That list is our onboarding path, from noob up to
vice-council-chairman of debops or whatever; Some pretty solid milestones on
the tool's learning curve.
Often, commercial projects focus on user acquisition. In terms of project
health, this project benefits when we get people all the way up to getting
involved with non-sexy maintenance.
There may be merit in discussing the non-profit scenario since, seen as a
stakeholder ecosystem, a way to financially support the ongoing development
would be a desirable way for many end users to play their part.
I mean, it's a tool people use for work work stuff.
Heh, I would totally work for a free software nonprofit.
Anyway, lol, I wrote a wall of text again.
Tasos
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEXbaOHtREtFSBLXcdOXguVye2c7EFAl8af/QACgkQOXguVye2
c7GnoA/9Gkiflzeru6znMZFUdteUR7pSgLK8ZU8Jq4zWCllmcqnMUtPQZB1baoeF
g61aIHH8+UKI8GRDt1vOLH+Rem/z/r0HIEqVonTnofvim9aH2oVodsxiWU4tlijU
i/1PN0F9Xvq+vslbIQ83UmMR6qWP++5Jo8nH6JuFtC9MUBI37Ab+q2ZOeGwTSOC6
cY3pxnG97bOYm94x9QKXdAD8esadM/Ad9WvC9mMfoQV8SP30al3zOgVUN/rC5hrA
vL6r1UjtEBYpPunmaU5I8mUKfM1kE5jNQnvvdmxtah06Hwvhqg56TR7IcW5rgfWN
YLBdVJKop1uwerI2kOUYYQM3GTVS28vukyzoNoXFIDtHMz8QldgHzFACSXegmacq
06R0l23Zd6/nP6YZmCWCwwbCTWKCR2jvQBVbPNNLU9stc0mrVyCiSm1um/r4d6Y8
ikdy5yj8GeTVFgHmFXWi9CQr7aaYXYBYCW4rZlsbfBzm+9qxiImTHtjiSbAhGxtk
g9x1HyMvg/qJHaA0BlYeXPaS90aKtVmTl/JsESy5rTt0ZAHa/d2Ulv41JW95btA7
2AISiP6jJhSnNUXRez51vmfy0chpxpBum9Lkeq7crd6rrNNbwnNdMjWtH6q7nDJy
wwPADdsIc08jM5zApXS35TrvmOSDbpOX8E8MGpL9dgOc1bnzfaY=
=vGt4
-----END PGP SIGNATURE-----
1:20 p.m.
On lip 24, Tasos Alvas wrote:
Ooops, I admired y'all sticking to the character limit, but then
I went and
did 80 instead of 78... The horror! I was crafting those mails for hours.
I just use vim, it has automatic wrap for files in the 'mail' mode.
I don't mean to restrict the conversation to my own point, but
the way I see
it the challenge at hand would be project health. Our goals, something like:
* Take stock of existing people an empower them to contribute
* Make room in the processes for the community to take over
* Lower the skill bar for meaningful contributions
A goal I would find fair for you particularly, would be to be able to bundle
tasks that don't need your overall understanding of the project so you can
focus on tasks others can't do and probably have more fun working at.
Well, what's fun for me is designing the infrastructure, trying out new things
and integrating everything at various levels. For example coming up with the
'parse_kv_config' and 'parse_kv_items' filters over the course of a few
roles
where in each iteration I honed in on a good generalized approach to
configuration was rewarding. Or finding out a good way to manage LDAP
configuration and data in the directory via Ansible. But that's basically the
crux of the DebOps project as a whole - bring different stuff together and
integrate it into a working solution. What I would like to do is focus on that
part.
That's why for me it's hard to delegate writing stuff to other people - if
I design a way to do something, it's basically identical to writing the actual
code, so I might as well do it right away... But that's probably something
I will have to rein in to allow for more collaborative work in this project.
Adding contributions to DebOps requires at least some understanding of how
everything works, and DebOps has a steep learning curve on top of Debian and
Ansible, not to mntion the whole sysadmin work with designing your
infrastrucure, etc. I'm not sure how we can lower the bar to entry apart from
documenting everything extensively.
Maybe more detailed instructions in the DEVELOPMENT.rst documentation that
show how contributions are reviewed and what common mistakes can be easily
avoided could be useful for new developers.
The use-case workgroups are a good start, I think, even as empty
concepts at
this point. They do represent something real about each community member.
Maybe we should brainstorm these categories and a list of roles to go with
each, and have those as additional role index flavors. On an issue then I
can wrap it up. Probably based off the existing tags in github.
I'm not sure I like the name "workgroup" for something that clearly means
use-case, I only like that it's clearly talking about _people_.
Tribes? lol.
Tagging issues for each of the tribes would be a good indicator for people
to swoop in and solve a problem in their domain.
The responsibility for each of them would be a different hat that you can
eventually hand over to other people, already there for them to claim.
You probably nailed it with the hat idea. I'm not sure about specific
categories from the point of view of a software project, but if we look at it
from a sysadmin perspective there's usually separation of concerns in larger
teams - networking, hypervisor management, application deployment, DBA,
firewall and security, etc. These roles could be applied in DebOps
development, where different experts in each field chime in when things get
added.
It will be heard to implement review notifications via codeowners though,
since a single file named 'defaults/main.yml' in most roles can have
configuration from multiple fields - firewall config, webserver, database,
LDAP, and so on. We would probably have to have a "general pipeline" of sorts
through which everything is pushed before being committed to the main
repository, not unlike LKML. Then people can chime in if they see obvious
issues, they can be corrected before final version is committed to the
official repository. And I guess this is why 'debops-devel' mailing list was
created, we would just have to start using it more.
Just thinking aloud here... I'm not sure how feasile would implementation of
this be in the current state of DebOps and how it is developed.
It might be even more sellable for people using debops at work to
justify
contributing to plumbing that they really depend on.
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.
Timing should also be probably taken into account, leaving slack for
the
community during the first months of a release cycle then wiping the low
priority stuff nobody picked up. As the community grows maybe we make an
event out of it.
Or we could go in the other direction similar to how Linux kernel went, and do
short release cycles every couple weeks or so. If your change or a new role
didn't make it to the last release, that's fine, just wait to the next one.
But that probably requires a dedicated person just for the task of combining
all the changes and making a release. Linus became de facto that person after
many years of developing Linux, when the community was large and diverse
enough to let the development momentum go on without his involvement. Not to
mention that the whole model of a 'stable branch' would have to be redesigned
and handled by more people. DebOps has a looong way for that to happen. For
now, I guess we're stuck.
There should also be a tag for `easy`. Like with that missing newline
that's
hanging on the issue queue right now. Just with a name that will not startle
the issue submitter.
Ah, actually github proposes `good first issue`. Hopefully contribs will do
a second one after that. :)
You mean [1]? Fixing that would require diving into the bowels of the 'pki'
role and messing with the shell scripts. I guess if you call that "easy", we
can go with that. :-)
[1]: https://github.com/debops/debops/issues/1424
I suppose `good first issue` also implies `priority:low`?
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.
[2]: http://karolis.koncevicius.lt/posts/improving_github_issue_labels/
> The https://github.com/debops/debops-keyring
Oooh I had missed that.
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.
Organizationally though, I mean, you care about it as a dev, and use
it to
verify project health, not to trust a release.
For me as a release manager (another hat, hmmm), GPG signing a release doesn't
really matter, that's more important for the downstream - eventual Debian
package will depend on a signed release to authenticate it.
Yeah I'm not married to github, either.
I guess an email to reach each contributor is enough to reconstruct the
community outside github. I'm not sure if requiring publishing one's mail on
the repo and packages is a good idea, though. LDAP on the debops infra? ;)
You might have a good idea, a proper LDAP server for various services in
DebOps could allow for even more "dogfooding" and provide access to the wiki
and other services if they crop up. I currently don't have access for a cheap
and performant enough VM to set it up externally. I'll check with my workplace
to see if I can have a dedicated VM for the project that could hold LDAP and
some other authentication stuff. Imre proposed access to a VM on his
infrastructure, I wonder if we could use it for that purpose...
> nobody reads the user manual.
SIR, I SHALL ASK YOU TO STEP OUTSIDE!!1 ;) ~style-force
Hook, line and sinker... :-)
Often, commercial projects focus on user acquisition. In terms of
project
health, this project benefits when we get people all the way up to getting
involved with non-sexy maintenance.
There may be merit in discussing the non-profit scenario since, seen as a
stakeholder ecosystem, a way to financially support the ongoing development
would be a desirable way for many end users to play their part.
I mean, it's a tool people use for work work stuff.
Heh, I would totally work for a free software nonprofit.
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.
[3]: https://en.wikipedia.org/wiki/Technical_support#Tier_4
Maybe someday. :)
-- Maciej
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-----
2:52 p.m.
On lip 24, Robin Schneider wrote:
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.
Sounds good. On the wiki (I need to set that up finally) we could index such
roles in one place.
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.
It's in Python? Awesome. In that case when the debops scripts are rewritten,
it could be integrated as a subcommand to help maintain the repository.
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.
Another thing the new scripts can take care of.
-- Maciej
3:02 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2020-07-24 14:52, Maciej Delmanowski wrote:
On lip 24, Robin Schneider wrote:
> 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.
It's in Python? Awesome. In that case when the debops scripts are
rewritten, it could be integrated as a subcommand to help maintain the
repository.
I don’t really think it should be integrated into the DebOps tools. Other
project might find yaml4rst function useful as well independently. With
integrate I meant integrate in the CI pipeline.
> 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.
Another thing the new scripts can take care of.
You have quite some plans for the DebOps tools, I like it :)
- --
Live long and prosper
Robin `ypid` Schneider -- https://me.ypid.de/
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE7eE3HRuH0o2l6AUVhv2YC78aQPgFAl8a3AMACgkQhv2YC78a
QPj4SA//dMU5zONZCwemCxudlucauxMNxkDOhlcCHFZxNo7NmTAOV8+BnFlb1L1/
/VJDr3HuwGeQNhY1K4runanK8eIEsyrnKKX715p4m79TaUObZOHNha5EkuMc7DAu
oJwnXUlnpql4AG5Jd+DNSLgWrjdU8hjixovjYHV/GuFQJvF/fqEQ9FQoeYmzBY83
KBr/PwwKRKmXHUrbG/2Da+B1SMyN54nEKbKJue/GFiJVrJf/Tf08EmDlxjB4IHum
4un7DcW9WcWUDgSf+KybHdo8IPJmb4sA/2obSQV4mk1CUNQyxV4LzazHGfbT7Cc1
ki0pk0rycZ51N9LEM+ICJzVxJjYwB+RCxc/z5wDK0O0IqdhcM7Zxguewxn4dUhpd
2BCyDjH84kxB/0U6ZPvm6XY3lSKVOIcbxX12sSenvsfpRqCkSEI7AeBYqJUnliCe
xTHCUMKUN7jstsxiuGc5tTmAkm3D8SLvP2yYUOcKE8o4I6u/QYK2aOc5pNOQVq2Z
1wMy6bYcvO+5YEnHc8snBPxIrNcGYwLtIPW3f6Y7rtQEmr/eDae3IYkP//rrZ3Wx
46kaDVAhAzU2nqccH6WN9UzolPs+rylnMo4RTfytphXYikglZryu1vcFRCmaeWUG
USsyjnw9dB83XjZCm7fbNUkbah0uP/oJJV28GddC1E/yXNxmbPY=
=er3A
-----END PGP SIGNATURE-----
3:42 p.m.
On lip 24, Robin Schneider wrote:
I don’t really think it should be integrated into the DebOps tools.
Other
project might find yaml4rst function useful as well independently. With
integrate I meant integrate in the CI pipeline.
Hmm, use for linting might be handy on Travis-CI to catch small stylistic
issues... I will have to check it out. I hope that a lint-only mode, without
making any changes to the files, is supported?
> Another thing the new scripts can take care of.
You have quite some plans for the DebOps tools, I like it :)
Switching to a subcommand model is a first step. After that adding new
functionality will be relatively trivial and we can go nuts with subcommands
for inventory management, a shell-like mode, monorepo maintenance, and so on.
I probably wouldn't try to replicate AWX/Tower though. When an 'awx' role is
added in DebOps, it could be an easy way to deploy it in production, an
alternative to Docker-based deployment. Maybe few people still like to do
things the old way. :)
-- Maciej
3:48 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2020-07-24 15:42, Maciej Delmanowski wrote:
On lip 24, Robin Schneider wrote:
> I don’t really think it should be integrated into the DebOps tools.
> Other project might find yaml4rst function useful as well independently.
> With integrate I meant integrate in the CI pipeline.
To clarify why I like the keyring to be integrated into the DebOps tools but
not yaml4rst:
The keyring Python code was designed from the start to be integrated.
yaml4rst on the other hand was designed to be independent from the start. If
you really want to merge it into the tools, I would not stand in your way, I
would just recommend against it. What I would like to see is it (the repo)
being moved to the DebOps org at some point in time.
Hmm, use for linting might be handy on Travis-CI to catch small stylistic
issues... I will have to check it out. I hope that a lint-only mode,
without making any changes to the files, is supported?
According to the docs, there is the --in-place parameter. I have not used my
own script for some time it seems ;-)
https://yaml4rst.readthedocs.io/en/latest/cli_interface.html
>> Another thing the new scripts can take care of.
> You have quite some plans for the DebOps tools, I like it :)
Switching to a subcommand model is a first step. After that adding new
functionality will be relatively trivial and we can go nuts with
subcommands for inventory management, a shell-like mode, monorepo
maintenance, and so on.
I probably wouldn't try to replicate AWX/Tower though. When an 'awx' role
is added in DebOps, it could be an easy way to deploy it in production, an
alternative to Docker-based deployment. Maybe few people still like to do
things the old way. :)
Sounds good.
- --
Live long and prosper
Robin `ypid` Schneider -- https://me.ypid.de/
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE7eE3HRuH0o2l6AUVhv2YC78aQPgFAl8a5rsACgkQhv2YC78a
QPi2uhAArq573cYYc6pP7jI76tE0eS7FO+uLORRuKh1N9e/RFury/zjr5Nyevdvn
PkyH6nRxIOO3ZhcfOWmapyGxetJOMzbXyvEmcKXqmyzxaL6UaXfWJe2gV96RzFQF
wX35e3iwcLesiC5oY/XHajcBYzO37RHk6k6kgUfKTb0jeVjBWIEtd+vtERvM4XmL
r3IBTdGQ9Z1u1eLx8XJzJlnANK+Iz7tWtoBsKNOnaAHcVK2O1cMHsROHotgK6HtD
BNCKxk+OuQ5GjyOiCfw+AhTKkTLDz03DTJN4L4sOUM5ij/BZd76Ft3Mm7qHPbZH1
qv57hv+V6M6XzQLC+QWPFVOcFAss51RqW4unsyXAmCm9ZpQ9siqFxmOFRQW1n2Pz
0+NwgxbIg9kY6taPoPeB9t+8tcJ8lsp7eWzv5pDCS4kGBJKLcU9ERltkir734Hgw
wcn/DnV3jtzkocx3URF2+wQx/TQcYJo4H2J4tTbAlqQA53PeZnxDgmkiyHiY1hQU
Fm/6NLdmVnahXzTyuoktQFs0bW1GvS9Dc/4lvGCNVAGzWva2KUoBkSH41KPu5+NT
ezRTYKDA0HDhWGAbG5VIPxa5H6sGlMmT4XOR7YUxybANJsxkXZ+HhMBXcT88gXxl
GwiUX3MnWKTL9PFiTYOHa8Kah/hHDfiOuQIehck8AbwbB6k1ocM=
=jhtK
-----END PGP SIGNATURE-----
10:55 a.m.
On lip 24, Robin Schneider wrote:
To clarify why I like the keyring to be integrated into the DebOps
tools but
not yaml4rst:
The keyring Python code was designed from the start to be integrated.
yaml4rst on the other hand was designed to be independent from the start. If
you really want to merge it into the tools, I would not stand in your way, I
would just recommend against it. What I would like to see is it (the repo)
being moved to the DebOps org at some point in time.
Sounds reasonable. Since yaml4rst is available in PyPI, we can install it in
the Travis-CI pipeline and use it that way. We can move the repository to
'debops' organization as well in the future, yaml2rst is already there.
According to the docs, there is the --in-place parameter. I have not
used my
own script for some time it seems ;-)
Great. So we just need to write the wrapper script that finds all defaults
files and feeds them to yaml4rst for checks.
-- Maciej
1:19 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2020-07-24 00:10, Maciej Delmanowski wrote:
On lip 23, Robin Schneider wrote:
> I guess it makes sense when changes to roles I wrote require my explicit
> approval from now on. I review all those changes anyway. So please wait
> with merging. I might take a few days until I can review PRs. I will now
> keep the codeowners file updated as well to reflect that.
I think that I can wait a week for a good PR to be reviewed by dedicated
people. if you want longer, post a comment in the PR so I know you plan to
do a review.
> One role I am not the best person to maintain is Apache. I am not
> actively using it but there have been contributors in the past. I would
> be happy to pass this one on to someone actively using it.
Sure. I'm updating the CODEOWNERS file so I'll remove you from apache
reviewers.
> My hope would be that people who use DebOps at work can get more
> involved.
Perhaps now that there will be a dedicated place to handle these things,
more people will be interested in participating.
> So for now, please wait for my approval, but no need to overdo it. When
> a commit touches all the roles for some style fix, you don’t need to wait
> for me.
Will do.
>> So that means the current project structure and stuff we're doing is
>> fine as-is for now? I can go with that, let's see where it will be in a
>> few years, then we can reevaluate when necessary, or when people start
>> complaining.
> Maciej was planning ahead :) I like the idea of making more use of the
> codeowners file and working groups.
The thing is, over the 7 years of this project's lifetime it was
completely overhauled twice - once to split a monorepo into separate git
repositories, and then after a year or so, to merge everything back. That
happened because I didn't really plan ahead far enough. It was costly, both
in time and additional overhead of developing tooling around the project to
handle changes. I would not want to make a similar mistake that would have
to be reversed again in the future, so exploring possibilities seems
reasonable.
> Bad git commit messages should not be merged and instead be reworked by
> the author. I don’t really see the need to rework commits after they are
> merged. History is history. When you change them post merging it would
> also decrease the learning effect. As long as the PR is not a critical
> bug fix, there is no pressure for bad quality being merged. So as long as
> there is something wrong with a PR, just leave it open. People interested
> will eventually find and work together to get it ready. The most scare
> people in a project are the maintainers. So I would just point out bad
> commits, give a hint and wait for it getting fixed.
Sure, I'll try to do that. Alternatively, I can just get a PR that is good
but has a few flaws and fix it myself. :-)
> I guess this depends on person to person. Maybe lets make the cut like
> this: If someone is in the https://github.com/debops/debops-keyring, they
> probably care enough for their signatures not to be altered in the master
> branch (cherry-picking is fine of course).
I think that there's no need to be picky here. If the commits are signed
by personal keys, I'll try to preserve them if possible. If they are signed
by the GitHub key (done via web editor), they can probably be overwritten
and treated as unsigned commits.
> Sounds like an idea. Just don’t make the description too long ;-) Because
> I like examples, here is what you may include about me:
>
> N: Robin `ypid` Schneider W: https://me.ypid.de/ D: Self-hosting with
> focus on Free Software, security, cryptography and privacy. D: IT System
> Engineer at https://www.geberit.com. No DebOps. SaltStack for SLES. S:
> Baden-Württemberg, Germany
Will do. Although I will probably go with RFC822 format commonly used in
Debian, so with more expressive header names.
-- Maciej
I agree with your comments and improvements. Not much to add to it.
- --
Live long and prosper
Robin `ypid` Schneider -- https://me.ypid.de/
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE7eE3HRuH0o2l6AUVhv2YC78aQPgFAl8aw9gACgkQhv2YC78a
QPjXpw//XVPvraf0mmbX40gSReAnwqgA6n73sN3D+TOqPd7RF8h4bkT5lOmaJlmU
K2BG4C3EQUTQd4ygAY/raXYNV4T1o/WlCyJX3ZPj0YhSqbYIs2bhO1kwehy6O5SI
krkKU4gcqbBfh6cbH0TYtlSGnfcWCgBC+SYXwb19m9jYxMDZKC1EK1sUtdm8sUtr
YdVbRNMFOzLI2RPmRWsKSg4mbLvYGdSyG6kAzoQSRb0CBEMe++OAgBXkCXCU74Eq
yCdl2A0ouUR/L97ueofR9bwsHW0aoOtNR77ComeNTPLJeVuhjrOVrnSstW+AF6I7
gt7QauxckqvFpxEA7wDb1Tgo9HLLHwGa8ydAZ2K02OuQPftCktaRXux0gkuVPwoW
F2gZvvjrBtIVG1xrX+j1/c7gMKtBFUNQv+p59dkdxvPc5219PfbfmhsDOTowlG85
dHUb+2cx32+XRD1SwWpWa5N50AuGqn78o+lWyeo14b/29rroCNPdI7mbKIXEQprI
ofA8yy5k+U+OlK/xGDhBzqQ6nWvpDLfkkEiJnlM+sncx+7iFhvyHkD+bpA7IWTf5
u1ZM/wwZl8WmVPd+6Iu5PSNBTVyJSkT0spPzpLN123g2j2pJamRiFKwKzg1VTxS0
5m7LhIFrmScQWhZlSldU3Kjo0HYSrubDIrhRi2i9AIMHNN6X9lo=
=73nE
-----END PGP SIGNATURE-----
5:31 p.m.
Hi Maciej,
Sorry for being late to the party. Here are my thoughts on this topic.
On Thu, 2020-07-23 at 00:26 +0200, Maciej Delmanowski wrote:
Both models assume that a large number of people participate in the
project,
so at the moment we don't have to worry about which path to take. But I
think that the model used by the kernel developers fits better for a project
such as DebOps, which is developed in the open, shared space by a dedicated
community.
Agreed.
Use of 'git' as the version control system also gives us an
advantage here
- since the project is maintained in a monorepo, we can leverage the
mechanism of codeowners[5] to give interested people "ownership' of parts of
the code. In such case they would take over reviews and maintenance of
selected parts of the codebase. That file is currently present in the DebOps
monorepo[6] but is not really used for anything - I'm keeping track on all
changes and nobody so far volunteered to help with reviews of a specific
role or part of the codebase, at least since that mechanism was added. If
you want to be included to easily keep track of parts of the repository that
interest you, let me know. In such case I'll wait with merging a given pull
request for your review.
I've started 'Watching' the monorepo which causes GitHub to send me emails of
all discussions and new PRs. I'll try to chip in a review here and there.
There are a few roles that I would like to become codeowner of so that I can
review changes before they are merged. I'll submit a PR to add myself to the
CODEOWNERS file.
At the moment in our contributor workflow[7] we mandate use of GPG
signatures in git commits and advocate for clean and concise git commit
messages[8], but that's rarely enfoorced. The output of 'git log -p --no-
merges' leaves a lot to be desired in the context of easily readable and
clean commits, and I'm guilty of it as well - partially because I'm trying
to record changes in the official Changelog file and I don't want to simply
repeat the note from the Changelog in the commit message. So now I wonder,
if a better focus on cleaner git commits in lieu of less verbose Changelog
file would work better in the long run? How many of you rely on the
Changelog to keep track of important changes (the upgrade notes are of
course another matter and should stay as they are)?
I always thorougly read the changelog and upgrade notes every time I update
DebOps to a new minor/major version, or the commit messages when updating to a
new patch version. Then I proceed to carefully running the new playbooks
against my infrastructure, first testing them out with the --check flag.
The changelog is great at showing what has changed from a user's perspective:
what changes to a role have been made, what bugs have been fixed, what has
been added or removed. Commit messages are different in that they are written
for developers and describe changes that may not be visible or interesting to
users. These commit messages are nontheless important and care should be taken
to write them properly.
So in my opinion we should continue with carefully writing changelog entries,
and try to improve our commit messages as well.
Or alternatively, should I point out all the issues in the pull
request
before the pull, then the original authors could rework the patches, rebase
where necessary and provide a set of clean commits? To be honest that seems
a bit imposing to me, but if more and more people are relying on my
judgement about what gets into the codebase, perhaps my standards need to
be higher?
This I think is the best approach. It ensures high standards in the master
branch, doesn't mess with commit signatures in any way, and is useful for the
commit author. I know I found your feedback useful.
Imre
1609
days inactive
1613
days old
14 comments
4 participants
participants (4)
-
Imre Jonk -
Maciej Delmanowski -
Robin Schneider -
Tasos Alvas