Re: Project development and governance model

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