View source for Kernel Plans
From Openmoko
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to Kernel Plans.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page:
Return to Kernel Plans.
This document explains the current kernel plan for the GTA01/GTA02 kernel. The idea is to share the motivations behind the actual decisions. This is a draft, and the relevant suggestions will be incorporated into it.
We would like to try this model for one or two months and if we find we are doing something wrong we will update the plans.
If the patch has not issues that we can tell and it is relevant it will be applied. If we can tell it is a good patch right away or that it is a critical fix we will just apply the patch.
Otherwise we will allow for two days before applying non-trivial patches to allow for community feedback and for feedback from subsystem maintainers. In the ideal case we would get ACKs from other developers (like "i like this patch") but we don't know if we can count on this.
We hope that developers actually care about the development branch. If they care, they will helps us reject patches that will likely cause trouble because it will break things. We will also get more testing.
We will tag stable kernels in the repository.
We know that people like forks and code that does not change often, but the linear model is working with upstream kernel (with a lot more people involved of course).
We could fork the current Andy-tracking into a stable kernel. But, should we really do it? People could fork a stable tree and cherry-pick changes.
We should have very basic GTA02 support upstream soon. Once we get to reach this milestone we will check what drivers can be included.
How to up-level the kernel to latest upstream version? (We can delay this decision for a few days).
Patchwork is a nice system. http://patchwork.kernel.org It does not replace a mailing list but it helps keep track of pending patches. We should use it.