Kernel Repository Process

It has been over a year since I formally updated the SELinux and audit kernel repository processes, and based on how things have evolved it seems we are due for another update. This time the changes are rather small, and shouldn't surprise anyone who has been following upstream development.

SELinux

  1. After the merge window closes upstream, patches will be merged into the selinux/next branch up until the merge window reopens. However, it is important to note that large, complicated, or invasive patches sent late in the development cycle may be deferred until the next cycle.

  2. Any patches deemed necessary for the current Linux -rcX releases will be merged into the current selinux/stable-X.Y branch, marked with a signed tag, and a pull request sent against linux/master as soon as it is reasonable to do so.

  3. During the development cycle Fedora Rawhide test kernels will be generated using the selinux/next and most recent selinux/stable-X.Y branches on a weekly basis, if not more often. These kernels will be tested against the SELinux test suite and made available to everyone for additional testing.

  4. Once the merge window opens a decision will be made if there is a need to rebase the current selinux/next branch on top of the recent Linux release. In general rebases should be limited, but rebases will be necessary over time to keep the selinux/next branch reasonably current. If the selinux/next branch is to be rebased, it should be done very early in the merge window and additional care should be taken to ensure that it passes all of the SELinux regression tests.

  5. After any rebases have taken place, the selinux/next branch will be copied to a new branch, selinux/stable-X.Y, and the branch will be marked with a signed tag in the format selinux-pr-YYYYMMDD. A pull request will be sent against the linux/master branch using the signed tag.

Audit

  1. After the merge window closes upstream, patches will be merged into the audit/next branch up until the merge window reopens. However, it is important to note that large, complicated, or invasive patches sent late in the development cycle may be deferred until the next cycle.

  2. Any patches deemed necessary for the current Linux -rcX releases will be merged into the current audit/stable-X.Y branch, marked with a signed tag, and a pull request sent against linux/master as soon as it is reasonable to do so.

  3. During the development cycle Fedora Rawhide test kernels will be generated using the audit/next and most recent audit/stable-X.Y branches on a weekly basis, if not more often. These kernels will be tested against the audit test suite and made available to everyone for additional testing.

  4. Once the merge window opens a decision will be made if there is a need to rebase the current audit/next branch on top of the recent Linux release. In general rebases should be limited, but rebases will be necessary over time to keep the audit/next branch reasonably current. If the audit/next branch is to be rebased, it should be done very early in the merge window and additional care should be taken to ensure that it passes all of the audit regression tests.

  5. After any rebases have taken place, the audit/next branch will be copied to a new branch, audit/stable-X.Y, and the branch will be marked with a signed tag in the format audit-pr-YYYYMMDD. A pull request will be sent against the linux/master branch using the signed tag.

For reference, the previous process was defined here.

UPDATE: The SELinux kernel process has been updated now that we are basing the tree against Linus' tree and sending pull requests directly to Linus.