FirefoxSummit/2006/ProposedSessions/Firefox 2 Postmortem

From MozillaWiki
Jump to: navigation, search

Session Title

Firefox 2 Postmortem

Session Leader

Mike Connor and likely Schrep


Review of the Firefox 2 development process good and bad


  • Quick review of requirements vs. end product
  • Problems with the plan and how we addressed that
  • Frustrations arising out of the process


Firefox 2 Postmortem notes

  • How did the process go – what did we plan to do, what did we actually do?

What did you like about the process?

  • Liked that anyone could join the drivers meetings
  • We pulled all-nighters to do L 10 N freeze
  • Good documentation on the whole process (documentation may be hard to find)
  • People had a better feel of what was going to be a blocker – less arguing over bugs, having actually valuable arguments
  • Decisions on UI changes were very quick/efficient
  • Definition around each milestone – what they were and were not going to be
  • Able to ship a major platform feature – JS17 – without breaking anything
  • We shipped on time, and were on target
  • Good that we are doing a postmortem
  • Getting better at doing shipping
  • Good job of making sure deadlines and milestones were broadcast
  • Simultaneous shipping in 37 languages
  • Project effectively included many new people as time went by
  • Daily triage meetings helped bugs get solved, and many people could run the meeting
  • There was good redundancy in releases – Schrep, Beltzner, etc. – nice that different people could manage
  • People able to disagree healthfully

What we could improve:

  • The website changes were late in the cycle
  • Bugs that get pushed off need to be tracked – those that were deferred need to be in next release
  • On some bugs the web tool team was brought in too late
  • Features landed too late – (said Seth) theme and major update
  • End-user documentation – Help was left to the last minute especially on localization
  • How will we deal with features in the future? Large ones….
  • Places didn’t make it into 2.0 – that was a good decision but we cut it too late in the process
  • Need scheduled or frequent product reviews to be scheduled – we need less emergency meetings
  • Design review features can be better planned
  • New features in L10nN – we need to inform important partners about them in a timely manner
  • The 181 branch and splitting 1.9 – was that a good decision? Was working on a branch ok?
  • The press release was sent to late to be localized
  • Hard to understand the state of work on blocking bugs – need to know what the current status is, real time or tracking
  • Where is there abandoned code? How do we identify?
  • Would like a 5 minute tutorial – how we do this, where is everything located? Understanding nomenclature would be helpful. Need a quick start guide.
  • What is blocking? – what it means, blocking plus and minus – need a definition
  • We had a lot of surprises – like RTL mode in windows – this created lots of extra work
  • We didn’t know about some issues - localization, storing data, internationalization, etc.
  • Accessibility – new press reorg, regressions, the day after the new theme landed they went through the whole theme – a design review would have been helpful before the change took place. Didn’t think of some stuff til it landed * lots of scrambling
  • Lockstep between Firefox 2 and was confusing – the interdependencies were not clearly communicated
  • Places situation – we didn’t really articulate why we cut it (Jeremy said)

Discussion: Which of these things do we want to tackle for Firefox 3?

  • Design reviews would be great – a Wiki that says this is the feature
  • Accessibility smoke test
  • L 10 N
  • Website integration – features that talk to our website or other people’s websites
  • RTL
  • Localization
  • Performance
  • Security
  • Theme(s) & theme interaction
  • Document whether it has any effect on the release process
  • Help
  • Support for compatibility, add-ons, extensions
  • Making sure the use cases are clear
  • Import export for data formats

1.8 Branch - good idea? (highlights of things mentioned)

  • Consider downsides and upsides of what happened
  • Trunks vs. branches
  • Cross commits
  • Auto merging
  • It was more manageable than people expected to check into both branches
  • Were Gecko 1.9 developers able to do what they needed to do? Because Firefox developers were on the branch
  • On Firefox 3 is it problematic that (other?) work is being done on the trunk?
  • At some point we have to branch….
  • Mozilla 2 will be branched from 1.9 – 1.9 stays on the trunk
  • Is it worth considering extending this model – branches merge back in
  • Having some code line that is stable is critical – how it happens is more problematic
  • Very little testing done on the trunk (said Ben S)
  • Minefield
  • Got more people on the nightlies
  • How do we get better at tracking goals and tracking what we leave out – need better design up front. Too many late saves

Interested Attendees

  • Reed
  • Robert Sayre
  • Mic Berman
  • Asa Dotzler
  • Ryan Flint
  • Jay Goldman (Radiant Core)
  • Dria
  • dolske
  • Gavin
  • biesi (maybe)
  • Jeff Walden (want to attend, but will depend on schedule)
  • Axel Hecht
  • Peter van der Woude
  • Nick Thomas
  • Steve England
  • beltzner
  • Steven Garrity (if schedule allows)
  • Basil Hashem
  • dietrich
  • bsmedberg
  • Preed
  • Sherman
  • AJ Ligneau
  • morgamic
  • pamg
  • Pascal Chevrel (if schedule allows)