Kernel Repository Process

28 Jul 2017 tags: audit selinux

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.

The process below applies to both SELinux and audit.

1. After the merge window closes upstream, a decision will be made regarding the need to rebase the next branch on top of the current Linux -rc1 release. If there have been a number of subsystem related changes outside of the subsystem’s next branch, or if the branch’s base is too far behind linux/master, it may be necessary to rebase the next branch. If a rebase is needed, it should be done before any patches are merged, and rebasing the next branch during the remaining -rcX releases should only be done in extreme cases.

2. Patches will be merged into the subsystem’s next branch during the development cycle which extends from merge window close 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. As a general rule, only small patches or critical fixes will be merged after -rc5/-rc6.

3. Any patches deemed necessary for the current Linux -rcX releases will be merged into the current 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.

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

5. Once the merge window opens, the next branch will be copied to a new branch, stable-X.Y, and the branch will be marked with a signed tag in the format subsystem-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.

UPDATE #2: The SELinux and audit processes have been merged (ha!) and the process has been changed to reflect potential rebasing to -rc1 at the start of the development cycle.

UPDATE #3: While the process documented here is not changing at this time, all future process updates will be documented in the README.md file in the base directory of each kernel subsystem tree. This post, and the process it describes, should be considered deprecated moving forward.