5 CommitPolicy

Steve Beattie edited this page 2021-08-26 20:21:20 +00:00

Table of Contents

• Committer Policies and Guidelines
• AppArmor Userspace
• Policies
• Recommendations
• Apparmor and the upstream Kernel

Committer Policies and Guidelines

AppArmor Userspace

Policies

1. Proposed patches for both trunk and the supported branches can be accepted and committed in multiple ways:

   • Submitted via a Gitlab merge request
   • Submitted as patches emailed to the apparmor mailing list for review.
     • For email submissions, it is important to ensure that appropriate testing has been performed, to at least match that of the AppArmor automated testing that happens through GitLab merge requests.

2. Submissions must be acked or approved by at least one committer.

   • Note that this is a mininum requirement, submitters and reviewers can request additional review.
   • Exception: if no feedback or approval is received in one or more week, submitters with commit rights may land the merge proposal to the appropriate branch. This is referred to as ACKed by Time-out. The person landing such changes needs to follow up in the appropriate channel to document that the proposal was landed under this policy.

3. Once approved, proposed changes can be merged or committed to the appropriate branch by either the submitter or the approver. Merge proposals submitted by non-committers need to be landed by the committer who approved the patch.

4. If patch or proposed change is NAKed, it should be discussed and given due consideration, and a revised submission should be proposed.

   • If there is a NAK from a core dev, and an impasse is reached (due perhaps to difference of opinion), then if three other core devs ACK the change, it will be accepted and should be committed.

     If this situation is ever encounterde, due consideration must be given to the NAK and a reasonable amount of effort should be taken to discuss and address the issue(s) raised, but a NAK is not an absolute veto and can be appealed and overriden where necessary.

5. Exceptions to the above policy:

   • Changes to profile abstractions that are specific to a distro (e.g. profiles/apparmor.d/abstractions/ubuntu-*) do not require ACKs for representatives/maintainers of those distros (e.g. jdstrand of Ubuntu).
   • Translations done through launchpad translations are considered a patch submission, and can be merged after review, without needing to be forwarded to the list or submitted as a merge proposal (unless questions arise, of course).
   • [Proposal from sbeattie]: changes necessary for the release process are recommended but not required to follow the approval process.
     • Examples of such things include changes to the common/Version and the library so versioning encoded in libraries/libapparmor/src/Makefile.am.

Recommendations

• TODO Propose a formatting rule of thumb for git commits.
• TODO Propose recommended merge commit and cherry-pick processes

Apparmor and the upstream Kernel

• Trunk commits are at the discretion of committers.
  • Non-committers need to send patches to the mailing list for review.
    • If ACKed on the mailing list by at least 1 committer, that committer is responsible for merging the commit
• Stable release updates should be sent to the mailing list for review but committers are not required to wait for the standard 1 week timeout.

---

Note that these policies are just minimum requirements; submitters and reviewers can request additional review.