On 1 June 2011 12:58, Christian Robottom Reis kiko@linaro.org wrote:
On Wed, Jun 01, 2011 at 12:51:12PM -0700, Deepak Saxena wrote:
All official Linaro builds are generated from a single git tree that has branches for different kernel versions that we build from being automatically updated during the build process. The git rev is embedded in the kernel package name (linaro-linux-<githash>-...) and also in the kernel uname so that it is immediately obvious what tree and set of patches it come from and the KWG or LT can go fix the issue in their private trees that then get pulled into the main git tree. We can also tag the git tree during a build and embed that into the kernel uname.
So your suggestion is that we have a tree to which we commit the result of the kernel source package build process? It's an interesting one; I'd like to know if this (or an approximation of it) is feasible.
No, not a tree of packaged kernels. I meant a single git tree that consolidates all the kernel source trees that we possibly build from to provide a single location where developers can grab any kernel we've used for builds. This would also facilitate easy diffing between kernel versions.
And thinking about it, John should already have this tree somewhere, right?
- What kernel tree it was built from (A URL to the git tree) - What revision (A revision ID) - What patches were applied on top of it (A URL to the patchset, maybe?)
By patchset do you mean broken out patches as in a quilt stack or a changelog of the patches? If someone has the git url and git revision, they inherently know what patches are in the kernel.
I was referring to the fact that for a source package (such as what we build the hwpacks out of) we have a base plus a set of patches which may not live in any tree. But answering the question above will probably answer this one too.
What's an example of such a set of patches?
~Deepak