Skip to content

Latest commit

 

History

History
46 lines (38 loc) · 2.56 KB

CONTRIBUTING.md

File metadata and controls

46 lines (38 loc) · 2.56 KB
Raw

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

About the repository configuration

  1. Before you start your work, make sure to setup the repository
    • This project uses git hooks with the help of lefthook. Make sure to have lefthook installed and run lefthook install to install the git hooks. NOTE: This step is necessary for quality assurance.
    • Optionally (but highly recommended) run git config --local commit.gpgsign true to configure your local working copy of the repository to automatically sign your work. Also add your e-mail address and public key to the allowed_signers file so others can confirm your work locally. See also Commit Signing for more information.
  2. This repository uses Conventional Commits. Make sure to follow the pattern. You can use a tool like commitizen to help you.
  3. Do not push your changes directly to the main branch! Create a pull request instead. After a code review by the project maintainer it will be considered for contribution.
  4. Release and versioning are handled by the maintainer as well.

Commit Signing

To make sure a commit is actually done by you and no one is impersonating you, git supports signing your work. This can be done either by using a gpg or ssh key. GitHub can verify a commit was actually made by you. The GitHub Docs about Signing Commits and this blog post by Git Tower about Setting Up SSH for Commit Signing explain how to create a signing key and configure git to use this key for commit signing. Both articles tell you how to add the public key to GitHub so GitHub can approve your work.

Versioning

This project uses the SemVer versioning scheme. However, this is not the full truth. The actual release version is much more complex. The project itself uses semantic versioning for all sources tracked by git. The actual release version on the other hand has a prefix. This prefix is the currently used version of Fedora.

This way it should be more transparent, if and more importantly why a new image version was released.