Releases/Fennec1.0maemo/Post Mortem

From MozillaWiki
Jump to navigation Jump to search

Agenda

Key question: how can we do this even better next time?

How did Fennec1.0 (maemo) measure up to the goals for the release?

What was good about the delivery schedule?

  • A successful 1.0 is always something to be proud of.

What caused delays in the delivery schedule?

What infrastructure improvements helped

What infrastructure aspects could still be improved?

  • devices
    • how much hardware is enough?
    • which platforms/devices? -- need to support the right platforms/devices, but each one supported is a hit in terms of time/money/focus

Effectiveness of PR and marketing efforts, and things that could be improved

How things went on "ship day", and what could be improved

  • last second changes:
    • single locale releases, despite nothing on that front for rc1-3.
    • partner repack surprise.
  • are these known/tracked issues beforehand?
    • communicated clearly? perhaps a tracking bug with dependencies on release blockers.

Roundtable (anything else that was missed above)

RelEng comments (Work in Progress)

  • The below should be taken w/ a grain of salt, as this is a version 1.0, and on a hard (mobile) environment. However, we can and should use hindsight as a way to learn for future releases.
  • Bug tracking:
    • blocker list should include blockers for *other groups*, not just mobile developers.
    • track everyone's blockers as dependent of the tracking release bug
    • if there are known blockers on a release, before the "go to build", it is by definition not a Release Candidate, and must be called alpha/beta... or the blockers are not real blockers?
  • how much hardware is enough?
    • what are mobile dev expectations for coverage?
    • buy more: meet developer expectations about wait times, talos coverage, and multi-branch coverage
      • also, allow for some to go down w/out forcing releng to reimage daily, allowing us to focus on other goals.
    • buy less: concerns about spending too much time/money on devices that we will quickly stop supporting.
      • attempts to cover multiple branches on checkin will result in highly spotty coverage, esp. in talos graphs
      • this will also force releng to reimage constantly.
    • concerns about cost - can we buy bulk, at cost?
      • will vendors supply us with more?
    • technical hardware/os contact for device setup help.
    • need clear indicators of what hardware worth the effort to get going
      • n800s waste of time (educational?)
      • n810s obsolete but we have scale
      • n900s the officially supported platform, yet we just got devices rc3 / 1.0 timeframe... fennec released with no n900s in production
        • n900s changed filesystem type between prototype and released version ?
      • need to do better if we hope to ship bundled
  • unittest failures
    • RelEng running unittests, but no-one is looking at them, so now hidden because they've been red / orange forever. They were green for a while, but drifted orange /red and no-one looking at them
      • significant loss of useful n810 cycles per checkin
    • unittests need way to denote fennec expected fail can be different to firefox expected fail
  • cross-group communication
    • forewarning to rel-drivers for coordinating on release days
    • clear handoffs between groups on rel-drivers
      • formal "go to build" on release-drivers with changesets
      • before starting official builds, wait for last landing to go green through all builds/tests/perf
        • one of the beta failed out with a compile error?
    • don't assume its always aki or joduinn doing a fennec release
  • Need clearly scoped objective on ship day:
    • thurs prep-for-release during mobile meeting only discussed multi-locale. no mention of single-locale or partner special repack
    • shipped single-locale even though they were not in RC2, RC3.
    • partner special repack
  • alternate platforms distracted from main release

Need fixing before we ship another Fennec

Doing a fast security release would be a problem right now (think zeroday on 1.0.1). Some/all of these would also apply to a WinMO1.0 release.