Patch Contribution Guidelines

Since our packages sometimes lag a bit behind their respective upstreams, AArch64 support may still have bugs that need to be addressed. Additionally as new AArch64 hardware is released, we may want to add support for it ahead of our upstream path. In order to do this and keep things functioning smoothly, we've got a few rules that we hope aren't too onerous for anyone looking to contribute.

• The patch must be accepted upstream.

This applies both to kernel patches, and bug fixes. If upstream isn't aware of it, then it's up to us to maintain the patch and support. The general mantra of "upstream first" benefits everyone. If a patch has not yet been accepted upstream, we will evaluate its approval on a case by case basis depending on why it has not yet been accepted.

• Patches must be additive in nature

This is mostly for adding hardware support, and only partly applies to bugfixes. You may not turn off features that exist in the baseline package in order to support a new feature. A common example of this would be disabling ACPI in order to add support for a new SoC.

• Patches must be accompanied by documentation Patches must include the following minimum documentation:

  • A link to where the patch can be found upstream.
  • What the patch does, or provides. This is so that we can update the changelog or release notes as needed.
  • How to test the patched feature, either as steps to duplicate a bug, or demonstrate that hardware works as expected.

• Patches are submitted to the mailing list for public review

We cannot accept patches that are provided under NDA, embargo, or are otherwise private. Since our builds and buildlogs are public, any patch submitted is to be considered public.

If you would like to contribute, please submit your patches to https://lists.centos.org/mailman/listinfo/arm-dev and welcome to the team!