Minutes from ARM kernel merge+packaging processes call 20100603

[Steve Langasek]

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-alignment>.

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 at ubuntu.com                                     vorlon at 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