Releases/Thunderbird 3.0rc1/Post Mortem

Post Mortem for the Thunderbird release of 3.0rc1 / 3.0rc2 / 3.0 (DialIn Info)

What went well

• Release Process - practice from beta cycles.
• Get Satisfaction
  • Really useful for finding the early problems.
  • Suspect this also diverted some bugs away from bugzilla.

What could have gone better, and lessons learned

Leading up to the release

String Freeze

• Two weeks after previous release date felt too little for final freeze.
  • Suggest three weeks minimum or to be more locked down before final beta.
  • Land bigger fixes earlier.

Code Freeze

• Not having clear feature freeze date made some decisions on patches slightly harder.
  • Current plan for 3.1 is that last 3.1 beta will be the freeze point.
• When branching need to think about flags a bit earlier.

Release Notes

• L10n like to stabilise everything earlier and have it all done at the same time.

Build

• Generally works well.
• l10n tagging failed on invalid revision for the 'ka' locale, we need a way to test these revisions before it's time to build
  • Due to copy/paste error.
  • gozer: will put together some more sanity checking code.
• Need to sign-off on hg.m.o/build/tools and make sure the signing box is updated
  • Standard: Needs adding to the release checklist
• Do we need some sort of quick confirmation that all locales have completed successfully in-between locale repacks & signing?
  • e.g. in build 2 Standard8 found that the first linux (el locale) repack had failed pulling from hg. Only easily noticed by counting directories (buildbot history isn't good enough).
  • gozer: Needs some sort of final check before signing.
• Single build wiki page gets cluttered/confusing when reaching a 3rd build, for instance.
  • Standard8: to co-ordinate ideas and try and suggest better ways.
• Creating the final THUNDERBIRD_3_0_RELEASE tags was forgotten and needed doing manually
  • Standard8: Need to co-ordinate with Linux distros a bit more (add more information).
  • davida: Need more information about when a release is available, so that we can tell them how to get it for releases.
• Signing is taking too long, downloading/uploading all the way to the SHR office.
  • gozer now has a new set of hardware for remote signing, will speed up signing.

QA

• Not enough migration coverage
  • We missed duplications of folders bug 505465.
  • Auth issues for some configs.
  • Need to store away TB 3 profiles and try in 3.1
  • Mozmill tests will also help.

• Didn't follow builds closely enough myself relied on driver for that.

• Missed a few spots on update testing for the last build.

L10n

• Website - need to build up l10n dev better.
• Need to understand process better.

Actual Release

• we needed to coordinate w/ pascal & webdev folks which surprised davida
• release-drivers weren't notified of release.
  • We didn't know about it until reed told us.
  • Apparently some members of the list are Linux distributions.
    • We do have some of our own Linux and non-tier1 OS system contacts, possibly needs expanding.
  • Do we need an equivalent list for TB? (and split the general driving from the actual release driving?).
• 1-day notice was possibly a bit short
  • Surprised some people.
  • We didn't notify justdave early enough and he then forgot for a while, and only notified the mirrors a few hours before the actual release.
    • Standard8 (check with MoCo): Do we need to have something better in place here, e.g. a mailing list that we can send to as well?
• Standard8 (add to checklist): mozilla.com needs updating with thunderbirdDetails as well (bug needs filing at release time).

Updates

• TB 2.x updates weren't initially 100% fully throttled due to a bug in aus (now fixed)
• TB 2.x updates are being offered to non-supported platforms (bug 534180)
  • Standard8 (add to checklist): Needs checking before release.
• Old RCx builds (not released) won't get updates.
  • Not really a problem. People installing builds should know/find to update themselves.
• Can we get some sort of automated aus checker, so that we enter the build id for each release, and check that we're getting served the appropriate updates? (and going back across all alpha/beta releases?)
  • This already done, but may need some tweaks.

Support

• Could have done with SUMOMO articles being able to be written on top-reported problems, so we could just direct folks to them.
  • Should be ready for major update.

Anything else

Actions

Attendees

• davida, clarkbw, gozer, dmose, Standard, rebron, _Tsk_, andreasn, bienvenu, bwinton