How do Linux ACPI Patches Get Into the Upstream Kernel?
- The community develops, reviews, and tests patches.
- Len Brown, the Linux ACPI maintainer, checks them into the ACPI git tree, and pulls them onto the test branch. (see Get Latest Source Code)
- Andrew Morton consolidates the entire ACPI test branch into a single git-acpi.patch in his "mm" testing release: http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
- Len moves mature patches from the ACPI test branch to the ACPI release branch, and sends a "pull request", asking Linus Torvalds to pull them into his upstream kernel.
- Distributors periodically re-base their products onto Linus' upstream kernel.
How Linux ACPI fits into the Linux Kernel Release cycle
Linus releases a kernel about every 8 to 12 weeks.
After a kernel has been released, critical patches are integrated by the stable team into a stable tree, while Linus moves on to the next release.
The next release begins with a 2-week "merge window". Linus requires all patches that change features to be available to him on the first day of the merge window, so he can order integration logically.
After the 2-week merge window is closed, all future patches to that release should be bug-fixes only, with priority given to fixing regressions.
What this means is that if you want to add a feature or a driver, you need to get it into Len's tree well before Linus' kernel release, so that:
- Len can get it through the ACPI test tree.
- Andrew can get it through the mm tree.
- Linus can pick it up on the first day of the merge window for the next release.
If you miss the merge window, it will be up to 3 months before the next opportunity.
But fixes to regressions are welcome at any time. However, if the fix touches a lot of code and has high risk, sometimes a simpler, less beautiful fix (okay, a low-risk hack) is needed for the current release. This same hack might be appropriate for the .stable release, as well. The hack can be replaced with a more complete fix in the next release.