Confirmed users
693
edits
Releases/Firefox 3.6/Post Mortem: Difference between revisions
Jump to navigation
Jump to search
Releases/Firefox 3.6/Post Mortem (view source)
Revision as of 19:46, 28 January 2010
, 28 January 2010no edit summary
No edit summary |
No edit summary |
||
| Line 30: | Line 30: | ||
*lack of changes on the front end made it easier to have a rapid beta cycle | *lack of changes on the front end made it easier to have a rapid beta cycle | ||
*PR: held dev news/moz blog posts until the best time for worldwide impact rather than pushing them out right away (ex. waiting until Monday morning to announce rather than doing it late on a Friday night) | *PR: held dev news/moz blog posts until the best time for worldwide impact rather than pushing them out right away (ex. waiting until Monday morning to announce rather than doing it late on a Friday night) | ||
*AMO compatibility issues didn't cause major release problems | |||
'''What caused delays in the delivery schedule?''' | '''What caused delays in the delivery schedule?''' | ||
| Line 40: | Line 41: | ||
**we should take a look at the last round of manual verifications and figure out how we can condense that | **we should take a look at the last round of manual verifications and figure out how we can condense that | ||
**focus more on the incremental changes per beta | **focus more on the incremental changes per beta | ||
*adding features later in the process causes churn in QA - having to write new test cases, etc - and distracts them from the work of shipping betas, etc | |||
*tegra project took away QA resources...should have asked for time estimate up front rather than just assigning the work without a full understanding of impact | |||
*still feels awkward and surprising that we're still finding sites that are broken with our JS engine even at beta 5 or RC (a big cause of respins late in the game) | |||
**some of this was b/c of changes later in the process (ex. beta 5) that caused the problems...need to be aware that these changes may have other repercussions (although most of the time the changes have to be made) | |||
*missed some Facebook compatibility issues, but a lot of that was on their side | |||
'''What infrastructure improvements helped''' | |||
*automated testing, branch mechanics have helped | |||
*having dirty profiles was incredible...helped us catch a lot of things | |||
*TS testing very helpful | |||
*lots of of ways of understanding the effects of code changes we were making as we were making them | |||
*kept Firebug compatible throughout all beta cycles | |||
'''What infrastructure improvements helped, and what could be improved?''' | '''What infrastructure improvements helped, and what could be improved?''' | ||
*automated testing for add-ons | |||
*would be great if there was a suite of Firebug tests we could put into the tree so we could understand when we're breaking Firebug (Rob has a patch for this that we could build on) | |||
'''Effectiveness of PR and marketing efforts, and things that could be improved''' | '''Effectiveness of PR and marketing efforts, and things that could be improved''' | ||
'''How things went on "ship day", and what could be improved''' | '''How things went on "ship day", and what could be improved''' | ||