Linaro Ubuntu LEB: Improving the relationship with Ubuntu

Linaro planning :
   Monthly goals/assignments in blueprints but longer term in backlog

Would help Ubuntu:
  + Better visability to long term Linaro plans.
  + Need advise / guidance on new features, espeically for features that would go into LTS releases.
  + Before Linaro move forward to new RC, Linaro should advise Ubuntu to capture a snapshot of the current kernel version.

Planning:
  + linaro is doing monthly/agile engineering execution and planning, but platform will maintain a roadmap with quarterly high level topics/goals that blueprints/work we plan for the next month typically should refer to.
  + this does not give detailed information about concrete, small features

Kernel:
what happens to kernel support/maintenance with linaro moving to TIP only approach both in kernel WG and landing teams
 + ubuntu takes stable release (and even RC versions from before)
 + linaro continously tracks tip for mainline kernels as well as ubuntu packaged kernel
  + if ubuntu wants to see higher enablement level guaranteed to be available in final 3.x release, adding tests will help ensuring it
 + linaro does not do maintenance after release (move on to next version) once stable release is out
  + ubuntu needs to do backports from that point on: same as before precise;
 + linaro
 + stable kernel does not exist anymore
 + ACTION: ogra and victor to check if backout policy also applies for armel port
  + if so linaro can start tracking precise from the beginning
 + automation of armel exists?
  + ACTION: asac to check if pulling panda images can get pulled into LAVA from ubuntu
 + omap3 could be automated with qemu; ubuntu is keen on keeping it because its a good mainline reference kernel
  + beagle XMs are also available in LAVA lab

gst-openmax:
 + Linaro graphics WG will not ship a single package for all SoCs
 + Ubuntu would like to see those packages in the archive early on during development cycle
 + ACTION: Linaro to work on policy/process to get packages into the development release
  + this depends on ubuntu solving quality issues (build images + boot being guaranteed will help us)

Sponsoring:
 + Ubuntu willing to do sponsoring
 + Linaro should _really_ use the sponsoring process for Ubuntu armel packages
 + Linaro to become a membership/developer-power granting entity for ubuntu
 + attract community that Ubuntu might not catch
 + ACTION: Linaro to setup a membership board so linaro can approve uploaders
 + ACTION: talk to community council to find out what policies need to be in place

SRUs:
 + linaro will update kernel till feature freeze
 + exercise and establish SRU best practices

libjpeg-turbo:
 + plan agreed with doko and RMs
 + linaro will deliver benchmarks for libjpeg62 libjpeg8 and libjpeg-turbe (with and without NEON)
 + linaro will setup lab testing

Release Transparency:
 + Plan needs to get posted to ubuntu-dev mailing list

Backlog:
 + avoid duplication
 + ship a livecd approach?

Can we really use the ubuntu binaries forever? LEBs might pre-feature new toolchain flags;
 + how can we stay at least as close as possible
 + build infrastructure is hard to reproduce and just live-build alone does not produce exactly what Ubuntu images are
 + ACTION: tgall and adam to work on a plan/solution and present

Refactor flash-kernel:

Would help Linaro:
+ Ubuntu has the policy that "broken" packages will be backed out.
  - broken defined as packages that don't compile or pkgs which are functionally incorrect
  - ogra/victor will validate backout policy and how ti applies to armel