Release Review: 2011.08

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

Release Highlights

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

Android

Highlights

  • Having dedicated infrastructure people help the platform group is great and should continue.

Issues

  • Communication
    • Feature propagation from the Working Groups to the Linaro Platform Team could have worked better. This should be driven by the WG. A staging build for features to live in while upstreaaming goes on is valuable. Improved by: a documented delivery process.
    • Long term WG goals vs. Team BP scope. In the case of libjpegturbo it appears that information got lost and there were discussion of the semantics of "done". Improved by: Better requirements traceability. BP authors should include links that help both the asignee and casual readers to understand the whole picture.
  • Planning
    • Toolchain modifications and new functionality share deadline. To allow for testing time, these activities must be serialized within the team. This is obnly possible of the input toolchain is delivered early. Improved by: Assert that toolchain delivery date is sufficiently early in the cycle.
    • We need to unify LTs interactions with Ubuntu and Android. kernels need to be done a certain way, branching needs to be done a certain way, bugs, enhancement requests, prioritization with the LTs other goals.

Developer Platform

Highlights

  • Able to deliver over 90% of listed blueprints
  • Delivered LT Kernel and Uboot SPL to Ubuntu

Issues

  • Communication
    • Require better feedback and communication from landing teams for Ubuntu and Android LEBs
    • Find a better way to communicate with Landing Teams
    • Find a better way to communicate with the toolchain working group
    • Action: dzin and rsalveti facilitate communication with marcin and toolchain group

      • Propose to integrate an email from each group at the beginning of each release cycle summarizing the release plans
  • Testing:
    • There was no weekly testing announcement; need to persuade @Linaro the high value of testing
    • Action: dzin and rsalveti to sync with asac and fabo to have a better plan for weekly testing

      • dzin sync with fabo to see if he needs any help
  • Issues with Linaro Connect:
    • Hacking sessions at Connect need to be managed better
    • Action: rsalveti and dzin to manage hacking vs. planning sessions better in future Connects

      • rsalveti to follow up, dzin for provide support
    • Compressed release cycle due to Connect
  • Subscriptions to blueprints need to be improved
    • Use the workaround to subscribe the team
    • Action: asac, kiko, james_w to improve Launchpad

      • ongoing
  • Hard to test and validate work that touches upstream
  • Ensure the announcement of the Development Platform releases at linaro-dev m-l
  • Find a way to fix bugs with minimal impact on development
  • Make sure all team members are available to attend Linaro Connect
  • It is vital that all important boards are available to the platform team for testing

Graphics

Kernel

Multimedia

OCTO

Power Management

Toolchain

Validation

Infrastructure

  • Effort going in to the release could be better spent improving the process
    • This isn't specific to Infrastructure, it's about Platforms and beyond.
    • Currently the monthly releases are taking a lot of time from the people involved. Much of this is re-spinning releases in order to try and squeeze some last features in.
    • That leads to a lot of time being spent on supervising the respins, re-testing, updating release info etc.
    • Doing this is something that is generally better suited to a CI-drived process, but we don't have that in place yet.
    • If we were to reduce the effort going in to the releases (for two or three months), and instead put that effort in to improving the infrastrcture to advance the CI processes, we could have better releases at lower cost.
    • Yes, we would have releases for those two or three months that were less good than they could be. However, that loss would quickly be eclipsed by the improvements we could get from investing in the infrastructure.
    • Given the right tools we could produce releases with more features that were better tested, all with less time investment and less stress, which would make everyone involved much happier.
    • The decision to try and push these features in to each release is driven by us, so the choice to do this is entirely in our hands.

Release

  • Weekly testing announcement sent but no testing reports submitted
    • This issue was raised since May. The fact is that engineers don't do it for various reasons and we don't get any testing report for these calls. Even for RC, we should chase and bug people to make it happen. Now, we try to explain that the testing is mandatory (especially the release response team). In addition, we changed the day of the call for testing to Monday so it won't interfere with the release itself and ensure we have a full week between each call.
    • Also, during a cycle we have 4 weeks:
      • week 1 (after the release), in practice we don't have much changes wrt the release itself. The weekly testing isn't very useful as the result are mostly the same as the RC.
      • week 2/3 are useful, it includes bug fixes but doesn't contain the WGs/LTs deliveries.
      • week 4 (release week) is really mandatory as it's the RC call for testing.
    • As a result, only the testing of the RC reflects the state of the released images. Previous weekly testing reports are done on the latest stable release which contains only bug fixes but not yet the WGs/LTs deliveries.

Key Points for wider discussion

  • Make sure all components get proper CI (Continuous Integration)
  • Work better with Ubuntu upstream. when delivering @Linaro, announce to Ubuntu that it is available so they can decide if they want to integrate it.
  • Oneiric:
    • Ensure a smooth transition
    • Initiate Oneiric testing on Lava
    • Make sure images are created against development releases

Lessons Learned

Category

Issue

Problem/Success

Impact

Recommendation

Developer Platform: Bugs

Sorting

Problems triaging and assigning bugs

medium

Include a topic on bugs in the weekly meetings

Android platform: Value

Deliveries

Need to better stage/demo features while upstreaming

high

WG/PT process alignment

Android platform: Value

Deliveries

Need faster distribution of enabled board functions

high

LT/PT process alignment

Platforms: Efficiency

Focus

Platforms should be better unified

medium

Android/Developer Platforms should align long term feature integration plans and present in unison

Platform: Team performance

Infrastructure

Success in Platform development

medium

Having dedicated infrastructure people help the platform group is great

Miscellaneous

  • AOB

Cycles/1108/Release/Review (last modified 2011-09-20 15:28:14)