FirefoxSummit/2006/ProposedSessions/Firefox 2 Postmortem
From MozillaWiki
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)