Kernel Repository Process

Update: new process defined here

In an effort to make it a bit easier to maintain the kernel-secnext COPR repository I’m making some slight changes to how I manage the SELinux and audit kernel repositories. The downside is that there is now going to be a regular rebase as part of the release cycle, but at least it will be well defined and part of the process, unlike the current reactionary rebases.

Starting with the next merge window, I’ll be following the process below:

1. When a new kernel is released, rebase the repository’s upstream branch to the tagged kernel release (or the latest LSM upstream branch in the case of SELinux) and apply the next branch on top of the upstream branch. Send a pull request for the upstream branch to the next level maintainer.

2. Create a new branch, stable-X.XX, a copy of the upstream branch that was sent during the merge window.

3. Reset the next branch to the upstream branch that was sent during the merge window. At this point the upstream, next, and latest stable-X.XX branch should be identical.

4. Accept patches into both the stable-X.XX and next branches; as necessary, send pull requests for stable-X.XX to the next level maintainer. Continue until the next kernel is released and the process repeats.

As in the past, this process is subject to change, but I’m hopeful that this approach should work for the foreseeable future.