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