FirefoxSummit/2006/ProposedSessions/Firefox 2 Postmortem

Session Title

Firefox 2 Postmortem

Session Leader

Mike Connor and likely Schrep

Summary

Review of the Firefox 2 development process good and bad

Agenda

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

Notes

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 1.5.0.8 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)