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-----