Please, stop it. Do it the way the kernel does it. A hierarchy of maintainers that reviews the work sent by others and a single person with commit access to the main repository.
I am amazed that these smart people have not realizead yet that unrestricted commit access is simpy a no-go, with or without signed commits/tags.
Compare creating a one line fix for a project on github and having a discussion and review to sending a properly formatted patch to a mailing list and following up on that.
I know that having properly configured mutt and git send-email eases most of these pains but not everyone uses mutt and browsers have better consistency between them than e-mail clients. You don't need to go through a guide to configure your browser to send patches and participate in a review (vs https://nanxiao.me/en/configure-thunderbird-to-send-patch-fr... ).
For the former:
* Create a Github account
* Fork the repository
* Set up the new git remote
* Push to that remote
* Open the pull request
* Wait for notifications via email
* Go back to the webpage and find the comment
* Modify the code, add, commit, push, and type a comment
* Repeat
Versus
* Configure git to use one's ISP's email server
* Run git format-patch
* Run git send-email
* Check email for replies
* Amend the commit, run git format-patch, and git send-email
* Reply to the maintainer email
* Repeat
To reply to emails, you can use any email client or even do that in the browser. You only need to use the format-patch and send-email commands to send patches.
I agree that letting everyone commit is a bad idea once you reach a certain size (though I prefer to limit commit rights to a group of code reviewers, which integrates nicely with github&co). But not every mozilla project has reached a size where the overhead is worth it.
https://www.freebsd.org/developers/cvs.html
Dragonfly and Illumos use git, though.
> A hierarchy of maintainers that reviews the work sent by others and a single person with commit access to the main repository.
This is surely the whole point of having a DCVS. You can just produce a request to pull and the person with push access can review it before it's committed.
Critical projects are used in self-driving cars now. It's time to grow up.
> ...
> Require all commits to be GPG signed, using keys known in advance.
Is it possible to configure "all commits gpg signed" on Github? I haven't seen this option.
Another interesting thing that Github lacks is signed git pushes (`gpg push --signed`) that allows audit logging who moved which object to which ref.
Settings > Branches > [Add Rule] > <Apply Rule To> "*" > check "require signed commits".
At least according to the help text:
> Commits pushed to matching branches must have verified signatures.
The problem is that they don't allow GPG keys to be sunsetted. "Verified" should be a property on the commit, not something computed. If I replace my GPG key with something more secure, but I have no reason to believe my former GPG key was stolen, I should be able to keep trusting the other commits.
This is what really prevents malicious code changes.
