Thank you for helping ArchZFS provide ZFS packages for Arch Linux. Start by choosing the repository that controls the behavior you want to change. Small fixes are welcome; a PKGBUILD correction or documentation improvement is a fine first contribution.
- Use
archzfs/archzfsfor package templates, OpenZFS versions and hashes, kernel definitions, build logic, release workflows, and the production Pacman repository. - Do not treat repositories such as
zfs-utils,zfs-dkms, orzfs-linux*as independent sources. Their PKGBUILDs are generated fromarchzfs; propose the source change there unless a maintainer directs otherwise. - Use
archzfs/archzfs-keyringfor key material and keyring tooling. Its local contribution guide takes precedence over this organization default. - Use
archzfs/archzfs-mirrorfor reusable mirror synchronization tooling. archzfs-testingis shared staging infrastructure for release-workflow changes, not the normal destination for user-facing fixes.
Search existing issues, pull requests, and Discussions before starting work. Discuss changes to release architecture, signing, trust, or shared staging infrastructure with maintainers before operating on those resources.
Follow the build and validation instructions in the target repository. Never include private signing material, access tokens, or other secrets, and coordinate with maintainers before publishing, signing, force-syncing, or deleting shared resources.
Keep commits focused. A pull request should briefly explain what changes, why it is useful, any relevant user or operational impact, the validation performed, and anything important that could not be tested.