Linux Linaro Kernel Releases "Post Mortem"
linux-linaro-tracking (aka "llt")
This tree has been introduced in this cycle. The idea was to use LT's tracking trees sharing the same base as topics (one topic per LT) - as many LT's trees as possible. The base of the 12.06 llt was v3.4. In the beginning of the month TI and Samsung were at v3.4, ARM was at v3.5-rc*, the other LTs were well behind v3.4, but later Samsung has moved to v3.5-rc2. The And I had to use some v3.4 based version of the Samsung LT's tracking tree which were saved (i.e. tagged) in linux-linaro-tracking.git. There is no guarantee that this saved version is the latest and greatest v3.4 based version of the Samsung tracking tree - the tracking tree is being rebased (not a history tree); the tag is dated June 13, and I've notice the move to the v3.5-rc2 a week after. We managed to add ARM to llt in 12.06 because it turned out that the ARM LT keeps the topics from the previous release in their git repo. And the previous, 12.05 topics were v3.4 based. The only drawback was that the previous topics were saved, not the "whole" tracking tree. So (violating the original ideology of one topic per LT's tree) I had to merge these topic myself. Luckily, this is not a big deal in the particular case of the ARM LT.
When using the v3.4 based tracking trees, the number of conflicts was very small - just 4 trivial conflicts when merging TI's and Samsung's trees. The ARM topics haven't produced conflicts (as expected).
LT's tracking trees should be tagged right before moving to a new base, so that the most recent version for every base were saved.
Need more coordination between LTs and DevPlatform on the kernel version used as a base for the LT's tracking trees.
linux-linaro (aka ll)
The multiplatform topic in llct moves mach and platform specific header files into other directories. Some ll topics add such header files, and the multiplatform topic has no idea of them (no wander). This has been fixed in my ll-12.07-last-minute-fixes topic. But the problem is that this fix doesn't fit into any single topic (neither the multiplatform, nor the e.g. ARM LT's one) - it can be done only on the merged tree. So the ll-12.07-last-minute-fixes has to be based on the ll tree itself, and the result is merging everything twice - pretty ugly. The possible solutions are:
- make the ll topics to be llct (vs kernel.org) based - not very realistic?
- extend ll-merge.sh script to allow applying patches on top of the merged tree (turn ll-12.07-last-minute-fixes topic into patch set) - kind of breaks the initial ideology; the patch set needs to be stored in the linux-linaro-manifest.git along with the manifest, pinned manifest, and solutions (to be able to reconstruct the tree later). Not very elegant as well.
Due to the current release schedule and the kernel.org updates schedule every second ll release will always be at v3.x-<the last rc before the release>, not at v3.x release. E.g. the 12.07 LEB release happend 4 days after the v3.5 release, and we had to stick to v3.5-rc7. At the 12.08 LEB release time, the mainline kernel would be around v3.6-rc3. For the 12.08 release should we use (one month old) v3.5 - to get a LEB release based on a mainline release, or move forward to a considerably more recent v3.6-rc3?
linux-linaro-tracking (aka llt)
The v3.4 igloocommunity tree (the current one for the snowball) could not be merged into (v3.4 based) llt tree: the igloocommunity tree has got stable (== not changable), and it has a conflict which prevents merging it as is into the llt (the similar issue is solved by different code in llt and in the igloocommunity tree). Future v3.5 tree for snowball would probably be llct based, and woudn't cause such merge issues.
Platform/DevPlatform/LinuxLinaroSummaryByCycle (last modified 2012-07-27 15:20:31)