Process changes for the audit tree

Hello all, Due to a few reasons, the most notable being a need to stop back-merging from Linus' tree, I'm changing the way I manage the audit tree. I apologize for any confusion this may cause, but this is a necessary change. First off, the audit tree remains in the same place: * git://git.infradead.org/users/pcmoore/audit * http://git.infradead.org/users/pcmoore/audit ... the changes are limited to the branches and how they will be managed moving forward. Ignoring master, there are presently three branches in the audit tree: stable-3.18, next, and upstream. The stable-3.18 branch holds patches that were submitted during the v3.18-rcX window. The next branch holds patches that were developed for v3.19 during the v3.18 window. The upstream branch is based off of the stable-3.18 branch with the next branch merged on top. This is the branch I sent to Linus last week and is currently in Linus' tree for v3.19. It will also form the base of the next branch once the v3.19 merge window closes. Moving forward I'm going to adopt the following process: 1. Create a new branch, stable-3.XX, set to the upstream branch that was sent during the merge window. 2. Reset the next branch to the upstream branch that was sent during the merge window. The heads of stable-3.18 and next should be the same at this point. 3. Accept new features into the next branch and fixes into the stable-3.XX branch. 4. As necessary, merge stable-3.XX into upstream and send pull requests to Linus. 5. When v3.XX is released, merge next into upstream and send a pull request for the upstream branch to Linus. Leave stable-3.XX untouched for future stable fixes. 6. Goto step #1. The big change here is the new upstream branch, but it is important to note that the next branch will now be reset/rebased on a regular basis (step #2 above). The reset is unfortunate, but necessary to get the stable fixes. It is also worth mentioning that while I don't expect to reset/rebase the upstream branch often, it will likely happen on occasion so we can avoid back- merging. When this happens I'll be sure to send notice to the list. Thanks for your understanding, if you've got any questions, let's hear 'em. -Paul -- paul moore security and virtualization @ redhat