Releases/Thunderbird 3.0b3/Post Mortem

From MozillaWiki
Jump to: navigation, search

Post Mortem for the Thunderbird release of 3.0b3 (DialIn Info)

What went well

  • Lots of good feature and bug work; overall response felt positive
  • Code-freeze -> ship felt very smooth

What could have gone better, and lessons learned

Leading up to the release

  • Weekly milestones
    • may have helped focus somewhat
    • enough overhead that folks didn't find time to keep their bugs up-to-date
    • weekly granularity too fine
    • extra beta help psychology, in part because we had so much in Tb3
    • limit scope early on
  • Continuous extension of schedule without dates
    • Allowed desired for a feature to trump all the advantages of agility
    • A disaster for anyone who wants to base things on the same code, especially SeaMonkey. Additionally, experience tends to tell that people bring in things more rapidly when they know firm deadlines.
  • Didn't have explicit discussion about how to hand-off between steps on the checklist; so far this doesn't appear to have caused any problems, but still probably worth doing in the future.

String Freeze

  • Little time for localizers between firm string freeze and cutoff for L10n builds
  • Would be good for localizers to have 2 workdays plus a weekend after firm string freeze and before builds are cut for opting in to L10n (some localizers only have internet access during the week, some can only do work on weekends)
  • KaiRo would propose to make L10n (opt-in) cutoff and firm code freeze align and do firm string freeze at least that period of 2 workdays + weekend before that. (IIRC, this is very similar to what Firefox does and allows us to start all builds, including L10n when firm code freeze is done.)
  • Very late announcement of final release schedule for localizers (slushy string and code freeze had already gone by)

Code Freeze

Release Notes

  • Probably missed carrying over important items for b2
  • For beta 4, should include all "What's New" sections from older relnotes in reverse-chronological order.
  • Should start on relnotes sooner (at code freeze time? details? need to discuss w/rebron)

Build

  • should we consider updating install.rdf maxVersion for in-tree extensions (DOMi, Venkman) as part of the release automation?
    • Standard8: DOMi is set to 2.1a1pre anyway.
    • Standard8: Venkman is set to 3.0.
  • When requesting bouncer entries, don't forget to ask for complete and partial MARs too (Std8 to talk to gozer)
  • Need to remember to clean out previous's version builds from nightly latest/ directories
  • /pub/mozilla.org/zz/rsyncd-mozilla-current.exclude needs to be modified to include the new release for mirrors to pick it up

QA

  • difficult to mobilize Community :
    • When schedule changes all the time.
    • When it's the middle of the summer.
  • Liked the use of try servers and early testing by the complete team of builds with the UI rewrite. We caught a lot of regression early and some ended up fixed by the time we released.
  • Good follow up on some crashers before and just after the release.

L10n

  • mail/locales/shipped-locales
    • Wasn't updated to the correct list of locales prior to the tag of en-US
    • Forced gozer to change it on the release branch, retag and regenerate the source tarball
  • uk opted in with an hg rev that didn't work.
    • gozer inferred what appears to be the intended tag, retagged, and repacked
    • dmose sent a message mail to the localizer and dev-l10n asking for clarification and updated the bug 504786
  • Communication was not optimal
    • not enough communication between developers and localizers about schedule extensions

Anything else

  • Potentially for use in next version, copied idea of Axel's L10n bug creator, and created one for Thunderbird use.
    • Provides us with a consistent set of bugs pre-formatted and commented.
    • Can tweak bugs before submission.
    • Reduces work on drivers.
    • Don't know if it will be used for security releases, but hopefully good enough for Alpha/Beta/rcs.
    • Index Page
    • hg repo
  • Automatic (or manual) updates still not available several days after the release.
    • We got moaned at on b2 for this, and we're getting moaned at on b3 bug 506230
    • Proposal:
      • Update MARs produced at same time as the signed builds and pushed to betatest channel
      • QA tests updates before release.
      • At time of release, enable manual updates on beta channel.
      • A couple of days later (assuming no major issues), make updates automatic.
    • Note, RCs get released on beta channel. Final we can do similar, but leave the automatic update a bit longer if we want (e.g. to first point release).
  • Important to communicate 1.9.2 plans clearly and loudly quickly after 3.0 release so (eg enterprise customers) can react to 3.0 release in an informed manner
  • need to firm up crash-stats.m.c update step, seems to be insufficient to ask for adding the release and next development release. ref bug 480728 MTBF missing Thunderbird 3.0b2 milestone, and development 3.0b3pre & 3.1a1pre // 3.0b2 topcrash no results

Actions

Attendees

Standard8, _Tsk_, sipaq, dmose

Retrieved from "https://wiki.mozilla.org/index.php?title=Releases/Thunderbird_3.0b3/Post_Mortem&oldid=166393"