Kernel Repository Process

Update: new process defined here

Just as the software changes over time to better serve our needs, so should our processes. Starting with the upcoming merge window, I’m changing the process used to manage the SELinux and audit repositories. The new approach is described below:

1. When it is time to send a pull request upstream (approximately one or two RC releases before the merge window for SELinux, during the merge window for audit), copy the next branch of the repository to a new branch, stable-X.YY, such that X.YY matches the version of the upcoming release. Send the pull request using the new stable-X.YY branch.

2. Rebase the next branch:
   • In the case of SELinux, rebase the next branch against the linux-security/next branch. It tends to be common practice for the linux-security/next branch to be rebased on a semi-regular basis against Linus’ X.YY-rc1 or X.YY-rc2 release, as a result the SELinux next branch may need to be rebased outside the regular merge window cycle.
   • In the case of audit, rebase the next branch against Linus’ latest stable release, the kernel release that started the merge window.
3. Accept patches into the stable-X.YY and next branches as appropriate during the development cycle. Send stable-X.YY patches upstream as soon as they have been reviewed and verified against the appropriate test suites. Continue until it is time to send the next pull request upstream.

For reference, the old process was defined here.