Commit Access (Dezyne Reference Manual)

12.7 Commit Access

Everyone can contribute to Dezyne without having commit access (see Submitting Patches). However, for frequent contributors, having write access to the repository can be convenient. As a rule of thumb, a contributor should have accumulated fifty (50) reviewed commits to be considered as a committer and have sustained their activity in the project for at least 6 months. This ensures enough interactions with the contributor, which is essential for mentoring and assessing whether they are ready to become a committer. Commit access should not be thought of as a “badge of honor” but rather as a responsibility a contributor is willing to take to help the project.

Committers are in a position where they enact technical decisions. Such decisions must be made by actively building consensus among interested parties and stakeholders. See Making Decisions, for more on that.

The following sections explain how to get commit access, how to be ready to push commits, and the policies and community expectations for commits pushed upstream.

12.7.1 Applying for Commit Access

When you deem it necessary, consider applying for commit access by following these steps:

Find two committers who would vouch for you. You can view the list of committers at https://savannah.nongnu.org/project/memberlist.php?group=dezyne. Each of them should email a statement to maintainers@dezyne.org (a private alias for the collective of maintainers), signed with their OpenPGP key.
Committers are expected to have had some interactions with you as a contributor and to be able to judge whether you are sufficiently familiar with the project’s practices. It is not a judgment on the value of your work, so a refusal should rather be interpreted as “let’s try again later”.
Send maintainers@dezyne.org a message stating your intent, listing the two committers who support your application, signed with the OpenPGP key you will use to sign commits, and giving its fingerprint (see below). See https://emailselfdefense.fsf.org/en/, for an introduction to public-key cryptography with GnuPG.
Set up GnuPG such that it never uses the SHA1 hash algorithm for digital signatures, which is known to be unsafe since 2019, for instance by adding the following line to ~/.gnupg/gpg.conf (see GPG Esoteric Options in The GNU Privacy Guard Manual):
```
digest-algo sha512
```
Maintainers ultimately decide whether to grant you commit access, usually following your referrals’ recommendation.
If and once you’ve been given access, please send a message to dezyne-devel@nongnu.org to say so, again signed with the OpenPGP key you will use to sign commits (do that before pushing your first commit). That way, everyone can notice and ensure you control that OpenPGP key.
Make sure to read the rest of this section and... profit!

Note: Maintainers are happy to give commit access to people who have been contributing for some time and have a track record—don’t be shy and don’t underestimate your work!

All commits that are pushed to the central repository on Savannah must be signed with an OpenPGP key, and the public key should be uploaded to your user account on Savannah and to public key servers, such as keys.openpgp.org. To configure Git to automatically sign commits, run:

git config commit.gpgsign true

# Substitute the fingerprint of your public PGP key.
git config user.signingkey CABBA6EA1DC0FF33

To check that commits are signed with correct key, use, for example,

git show --show-signature <hash>
git log --show-signature

12.7.2 Commit Policy

If you get commit access, please make sure to follow the policy below (discussions of the policy can take place on dezyne-devel@nongnu.org).

Ensure you’re aware of how the changes should be handled (see Managing Patches and Branches) prior to being pushed to thegn repository, especially for the master branch.

If you’re committing and pushing your own changes, try and wait at least one week (two weeks for more significant changes, up to one month for large changes) after you send them for review. After this, if no one else is available to review them and if you’re confident about the changes, it’s OK to commit.

When pushing a commit on behalf of somebody else, please add a Signed-off-by line at the end of the commit log message—e.g., with git am --signoff. This improves tracking of who did what.