-- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org == Attendees == * Leann Ogasawara * Steve Langasek * Andy Whitcroft * Nicolas Pitre * Amit Kucheria * Loïc Minier == Discussion == https://wiki.ubuntu.com/Specs/M/ARMKernelVersionAlignment There were UDS discussions on patch handling and ARM maintenance, but while spec-ing we realized we needed a slighlty different process ARM has a wide variety of SoCs, more than just CPUs OMAP support is very different from Freescale etc. Because we want to upstream patches and merge them in Ubuntu, it's best to have a tree with the OMAP patches both for upstreaming and for merging in Ubuntu "Merge owner" would merge all these ARM trees together regularly, but the resulting tree would be volatile Ubuntu kernel would be merged into that tree as well Would we maintain an arm branch and send pull requests regularly? Not really, we would rather throw away old version of the patches and send new ones This would be a bit like linux-next / arm-next Idea is to distribute support of the various ARM platforms, and not have it in the Ubuntu kernel right away Final merge would be done just before Ubuntu kernel is frozen Goals: * trees are mergeable upstream or in Ubuntu, feature trees basically * not one merge request towards Ubuntu per SoC, but a single merge request of everything ARM to Ubuntu lool: I see the following issues: * will that cause conflicts? * will we get the same quality as a result of the e.g. monthly merges every month, or might that regress by surprise Nicolas explains that merges would be very frequent, e.g. daily, not monthly. Could push daily PPA builds for testing Only the individual hardware owners can test the kernel on their hardware What about kernel version skew between BSPs? Would have to be a separate source package and would not be part of the integration merge Which platforms would we track? OMAP is the only mainlineable one right now Dove might (according to Amit) or might not (according to nico) move to mainline soon, but is easy to mainline Freescale was planning .34, might be a challenge to move to .35 We're trying to help resolve the blockers when people are trying to mainline patches We expect to integrate TI OMAP4, Freescale, Samsung, ST/Ericsson One idea is to have a linux-arm git tree with all the ARM stuff and the Ubuntu tree merged in; master branch would be the Ubuntu delta Would start with current master branch; in the future might split things like intel specific bits or powerpc bits or whatever into separate trees What about conflicts? Depends on the conflict; if there's a large conflict, then that means we need a new topic tree Would use a fixed list of trees which are mixed together daily in the same order Would probably also need an ubuntu-arm packaging branch, for the arm specific packaging How will we merge changelogs? Cant get list of changes anymore due to the use of rebased/rebuilt from scratch trees Package would carry the SHA1 of the tree it was built from Would keep tags for reference purposes Changelog would mention sha1 hashes of individual trees Do we want a process for trees we can't merge? Let's wait until we see this issue Ubuntu kernel team would own ubuntu-maverick.git master obviously Linaro would own the integration tree; the Ubuntu kernel team will pull specific versions for upload and tagging in the main maverick tree upon request This guarantees we can reference them in the future for the package history Packaging would be cooperative; not sure where the ARM packaging branch would live, nor who would maintain it Do we run the risk of losing Ubuntu specific changes in ARM specific trees? e.g. CONFIG changes Config validation is an issue, works well when the configs are in the same tree, but the config checker does not cover enough configs; kernel team is working on covering more configs Every maintainer of a board should maintain the configs which are required for this or that board Should that be done by the CONFIG system? Hard to do because it depends on what gets merged? * danger of defconfigs provided with the per-Soc branches diverging unchecked from the stock Ubuntu config * mitigated by the Ubuntu kernel tree config checker, but this doesn't have full coverage of the config options yet * defconfigs should be sorted upstream * two-pronged solution; defconfigs need to be sorted upstream, but in the distro we need something viable in the short term * identify the minimal set of config settings that need to be set for an SoC and append these to the standard Ubuntu config? (Long discussion about handling of defconfigs upstream) * Need to be merging everything in a single kernel tree to make sure this continues to work * But building all the kernel images from a single source package is too slow: we need separate source packages per ARM kernel flavor to be able to build them in parallel on the buildds * could use a single tree and post-process the packaging to filter which set of packages are built * Steve doesn't like this approach and would like to keep one branch per source package for the ARM packaging bits, to avoid autogenerated source packages; these branches then can individually be merged with the main ARM integration branch == Actions == * nico to be the daily arm-next merge monkey :-) * nico to provide a proof-of-concept merge tree for apw to review and provide input on * apw to act as distro contact for packaging / integration issues of ARM trees * Ubuntu kernel team to provide glue to generate the changelog entries for the ARM merge on top of the current Ubuntu changelog, taking information about the sha1 of each merged branch from the git commits of the integration branch * Linaro SoC tree owners to identify the minimum set of SoC-specific options that are required, to append these to the bottom of the Ubuntu config