Linaro release process improvements

Agenda:
Current release process - what's the current process?
 * Monthly cadence (iterative), running on approximatively 4 weeks
 * Components release (one week before platform release, on Thursday)
 * Platform release (last Thursday of the month at 16:00 UTC, Release Candidate available on Monday)

Release internals - how the release works?
 * Planning phase (beginning of the new cycle, end of previous cycle)
   * using blueprints: commited to deliver essential/high priorities, backlog milestone
   * view/status available on http://status.linaro.org/
 * Execution phase (mid-cycle)
 * Release phase (end of cycle)
 * QA testing (automated and manual)
 * Post-mortem (lessons learned)

The road to Continuous Integration - how the CI is going to transform the release?
 * source code repository
   -> daily packages build (Ubuntu specific)
      -> daily images build
        -> daily images testing on LAVA
            -> bugs reporting
                -> release reporting
 * Metrics: bugs, benchmarks, etc...
 * Roadmap: http://linaro.kanbantool.com/public_view-9487de29a82f2.html

Notes from LDS:
[zpfeffer, 2011-10-31]
Current Release Process

Monthly
Last Thursday of the month

How do we decide what goes into the release?

How do we communicate which patches have landed?
    Track which patches have actually landed in the tip?

CI works if we fix things when they break
    Android has to rebase each day for some repos, kernel gets rebased

Need to track Linus-HEAD and Deepak-HEAD

ACTION: Deepak: What does Linux Linaro's kernel need to be
ACTION: Ricardo: Discuss Linus HEAD, Linus NEXT
ACTION: <platform team>: kernel flows docs
ACTION: Zach:
ACTION: Deepak: Will look at each kernel that we ship and say which patches made it in

Release Internals

Planning, Post-mortum
   Essential and High and committed to be delivered

BPs used in status.linaro.org

Alexander
   A few things
      Planning takes too long
          Expectation: Post-mortum on Friday 23:59 UTC
              Plan is available on Monday UTC 23:59
              You should have the backlog sorted by priority
          Should happen on Mumble not IRC

    QA Testing
        Happens on release
        Android has a QA engineer
        Need to test components
        Components needed
        Release checkpoint shipped along with components

ACTION: asac: will drive test standardization across the industry.

CI

Android is here, need to get Ubuntu there
Disk space issues, staging PPA and

ACTION: Ricardo: Need disk space
ACTION: component release testing
ACTION: Paul: Fix deployment and roleout
ACTION: Paul: Need smoke tests and ability to back out
ACTION: Ricardo and Zach: File bugs

[fboudra, 2011-10-31]
miscommunication with the kernel delivery, working upstream. Actual code isn't available in the Platform.
-> Android tracks LTs TIP kernels
-> which tree should we track and release?

disk space issue (should be fixed)
-> who write test cases/responsability?

LAVA deployment process shouldn't be disruptive

ACTION: deepak: discuss about linux-linaro at the kernel release/mapping session
ACTION: everybody: stress test lava