Hi everyone,
Below are the notes from a conference call today for hashing out the details
of integrating Linaro's ARM kernel work into the Ubuntu Maverick development
cycle. I've extracted a couple of action items from the discussion that I
think need to be addressed soon to get us to the next level, but we didn't
identify owners for these during the call; please review these and confirm
that they look correct.
Nico, if there's consensus on these action items, we should capture them as
work items on the whiteboard in
<https://blueprints.launchpad.net/ubuntu-arm/+spec/arm-m-kernel-version-alig…>.
Thanks,
--
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(a)ubuntu.com vorlon(a)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
Hi All,
I am Madhu, recently joined the list. I am excited about the Linaro
project. I am working as Linux embedded engineer for ARM platform. I am
looking forward to contribute in this project.
Regards,
Madhu
