Release Review: 2011.09

  • Created: David Zinman <david.zinman AT linaro DOT org>

    Past reports

Release Highlights

  • Include any major updates, good, bad news and issues.
  • Include highlights and lowlights.
  • Things to improve.
  • Include relevant links.

Android

Highlights

  • Earlier Toolchain release date was very helpful.
  • Tracking toolchain tip was helpful.
  • LTs were more responsive to bugs.

Issues

  • BPs can sometimes be unclear. What to do and and why.
    • Suggestions:
      • Make clear where the BP comes from - traceability to requirement.
      • Be prudent with Headline and Done criteria.
      • Make sure BPs are gardened regulaly and WIs are updated.
  • LTs and WGs are not agreeing with all our plans that involve them.
    • Suggestions:
      • PM to add affected groups to each BP and Bug and talk one-on-one with them and their PM at the start of the cycle (maybe co-team kickoffs)?
  • Some tasks could not be completed in the cycle.
    • Suggestions:
      • If something doesn't work after a week of effort, lets regroup on it.
  • Its hard to see which groups need to work on a BP.
    • Suggestions:
      • Assignee must assert that co-workers are subscribed and properly bugged for progress.
      • Use the prescribed syntax in WI for describing who does what.
      • The PM should also be bugging the other teams PM.
  • iMX53 was difficult.
    • Suggestions:
      • We need to gear up with JTAG debuggers.
      • We need to get the iMX53 LT more engaged.
      • Sometimes we can't have our way (probably we'd have had less trouble if we had started with the LT kernel than with trying to build a LT/jstultz hybrid).
      • Get SoC documentation.
      • Ask LT members for PoCs.

      • Work the community sites.
      • Read commit logs for PoCs.

      • Post on android-building and android-platform.
  • Blueprints that have unfinished items should not be marked as 'implemented' until a review is done. This was the case with https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-snowball-a-release.

Work Items

Developer Platform

Highlights

  • Production development cycle since there was more time for development.
  • CI for daily builds was started.
  • Evaluation of derived distro worked well.
  • Debug symbols for kernel delivered: makes tool building easier.

Issues

  • Work items should be more descriptive in order to be more understandable.
  • Some components from the working groups were not delivered on Thursday
  • Communicating respin: getting better, but a defined process is needed.
  • Separate upstreaming activities from monthly cycle.

Work Items

Graphics

Highlights

Issues

Kernel

Highlights

Issues

Multimedia

Highlights

Issues

OCTO

Highlights

Issues

Power Management

Highlights

  • Team is well set with the process, no issue was reported.
  • Lessons Learned: each month PM and TL set and assign the blueprints and work items in launchpad then tell the team about them. In another word buffer the engineers from Launchpad modification.

Issues

  • Constantly in the planning mode, as soon as a month is over, the next starts. Maintaining the plan is currently very expensive.

Toolchain

Highlights

  • More than one person can push release candidates builds, now.One can push the build and another can analyze the results. Making use of the time zone difference, this method works great, one can push the builds go home, others can analyze the build when they login

Issues

  • Too many bugs before the release, need to address bugs before they accumulate

Validation

Highlights

Issues

Infrastructure

Highlights

  • Linaro CI build service is now available for wider beta testing for Linaro engineering teams.

Issues

Release

Highlights

  • Freescale and ST-Ericsson LT have notified their release, respinned their hwpacks and asked for approval.
  • Overall the release is running smoothly. Each monthly release is going better than the previous one.

Issues

  • Android: Linaro Android RC images announced later than expected. The URLs to the images should be communicated as we need them for the call for testing. Monday 16:00 UTC should be targeted.
  • Graphics WG: glproxy wasn't released as expected.
  • LT: Kernel has been released without notification. Tarball created/released while a tag wasn't available. I'm not even sure the source code tarball is the one used in the hwpack.
  • Developer Platform: TI LT kernel packaged from git tag. respinned lt-panda hwpack without approval. u-boot-linaro was released later than expected. last minute integration issues with u-boot-linaro (regression spotted with RC).
  • Validation: lava-dashboard and lava-server were released later than expected. lava-scheduler-tool and linaro-python-dashboard-bundle weren't planned to be released.
  • Toolchain WG: cortex-strings release delayed. It required to poke TL/PM to get a status.
  • General:
    • Still a lot of work to do on QA and release testing. We need lava-qatracker and mandatory testing.
    • Headlines came late in the cycle. They should be defined during the planning phase, right after the release.
    • Ubuntu-build jobs should be scheduled at 16:00 UTC instead of 00:00 UTC.
    • Image respin should be communicated (including rationale, bugs, etc...).
    • It's like domino: if components aren't released in time, Platform have less time to resolve issues spotted on integration.
    • Release Team should be in the loop for each topic affecting the release: delay, issues, respin, etc...

Key Points for wider discussion

Lessons Learned

Category

Issue

Problem/Success

Impact

Recommendation

Monthly Release

Pm & TL do most of the Launchpad work (leg work)

better team acceptance of the process

continue doing until team is ready to handle themselves

roles

Make sure every role has a backup, has 2 people, that can do it

better coverage, when the main responsible is on leave

bugs

Too many bugs to handle before the release

should address bugs continuously and let them accumulate

Monthly Release

Post-mortem came late

There was not enough time to deliver the post-mortem quickly after the release

Other issues delayed

Start the post-mortem process earlier within the release cycle

Miscellaneous

  • AOB

Cycles/1109/Release/Review (last modified 2011-10-06 22:59:13)