On Wed, 1 Jun 2011 13:17:38 -0700, Deepak Saxena dsaxena@linaro.org wrote:
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.
I don't think that a centralised solution to this is worth pursuing.
Take the Landing Teams for instance, I'm sure they would appreciate some of these facilities for their private hwpacks, but we can't pull their trees in to a central place.
And thinking about it, John should already have this tree somewhere, right?
http://git.linaro.org/gitweb?p=people/jcrigby/ubuntu/linux-linaro-natty.git%...
I think that we can fairly cheaply put a file/version suffix/something in the kernel binary package that points to the tree + ref that it was built from.
We can then generate a report when building the hwpack that consolidates this information.
This is also useful in that it's not specific to the kernel, so if we put that file in other packages too they will be picked up (u-boot anyone?)
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?
I don't believe that this is the case for the kernel. Everything should be in John's tree referenced above, and you can use git to find out which patches are in any other tree that you care about (nico/linus etc.) if that information is needed for what you are doing.
I don't think we should be looking to attribute the provenance of every line of source that ends up in the hwpack in one report, we just need to shorten the chain to find the information that you care about.
One very cheap thing we could do is to produce a report when building the hwpack that tells you which archive each binary package that was used came from. You can sort of do this now (assuming there aren't clashing versions), but it's a pain. Once you know that you can find the source package. So this is a general solution, but we can do much better in specific cases.
Another cheap thing to do would be to dump the config from the kernel package in to the output dir, so you can see the config without having to download the hwpack or produce an image. This can be useful, much like the new .manifest that lists the packages included and their versions is useful if you want to know if the new hwpack build picked up the fix for some bug in the latest upload.
Thanks,
James