Releases/Rapid Release Process Post-mortem
From MozillaWiki
< Releases
Contents
Overview
This is a post-mortem on the new rapid release process. We will only talk about items on this list. If you want to talk about something, add it.
Each section will take a max 2 hours / number of items. We will loop back around and talk about a section more if others don't take the full allotted time. Individual meetings will be scheduled to talk specifics if the section requires it (not everyone will care about all sections).
Live notes will be taken on Etherpad and added here after
Meeting details
- Thursday June 30th, 10:00am-12:00 noon PDT
- 650-903-0800 x92 Conf# 8605 (US/INTL)
- 1-800-707-2533 (pin 369) Conf# 8605 (US)
- join irc.mozilla.org #planning for back channel
- 10 Forward conf room in MV
Process communication
- Was it clear?
- Did using GitHub work decently?
- Releases blog...good or bad?
- Wiki...good or bad?
- dev-planning as discussion medium...useful?
- Did you feel your input was taken seriously?
- When a decision was made, was is clearly conveyed the direction and why we were going that way?
- value of same person saying "go to build" for firefox and fennec on same changeset, at the same time.
Pace / schedule
- We understand that Firefox 5's schedule was a bit wonky...do you know why as well as what to expect for the schedule going forward?
- Based on Firefox 5/6, do you feel the 6 weeks of development on mozilla-central is too short, long, or just right?
- Based on Firefox 5/6, do you feel the 6 weeks of stabilization on mozilla-aurora is too short, long, or just right?
- Based on Firefox 5/6, do you feel the 6 weeks of validation on mozilla-beta is too short, long, or just right?
Repo structure
- Are the repo rules/expectations clear?
- How do people feel about the various repos and rules?
- Do you agree with what we have taken on mozilla-aurora and mozilla-beta? Do you think we need to be more lenient or lock down more?
- Did changing the repo location of mozilla-aurora to releases/mozilla-aurora after the fact cause any headaches?
- Were the repos set up to allow us the flexibility we needed to control the update frequency across channels?
Bug management
- Does the way we are tracking fixes/issues make sense?
- Was the communication clear?
- Any suggestions on ways we can improve or tweak the process now that we have been using it?
Feedback
- Do you spend a lot of time tracking down what channel / version a user is on when issues are found?
- Are our channel feedback mechanisms (bugzilla, input, SUMO, socorro) sufficient in the new process?
- Can you use crash-stats as effectively as before the rapid release process?
Channel update communication
- Did the way we talked publicly about releases on the various channels make sense?
- Do you understand the difference between the source migration date and the date updates are available on the channel? If not, how can we communicate that better?
- Are you concerned about our communication not emphasizing of version numbers?
- What are your impressions on the way external people (users, press, etc) viewed the channel updates?
Add-ons
- Note that we aren't going to solve this here, merely want to talk about it at a high level
- Effect on the add-on population
- Do you think we did enough to increase add-on compatibility?
- Communication around add-ons
Other topics that will be discussed at later meetings, not here
Rapid release and the enterprise
- We have no desire to talk about the 3-5 dev-planning threads with 50+ messages here
Feature pages
- There is a future meeting later, more details coming from deb
Meeting effectiveness
- Does it make sense to keep the Aurora and Beta channel meetings separate?
- Does it make sense to have triage and the channel meeting the same?
Source migration mechanics
- Follow-up meeting details
- Does the way we are merging make sense now that we have done it?
- Should we do a null merge?
- Does l10n need to merge the same way or can they be different?
Mechanics of the Firefox 5 release
- QA test time
- Poor specification of update snippets required, revisiting of work when generating custom updates
- Web push w.r.t the release
- useful etherpad checklist of "what needs to be done", "by whom", "scheduled for what time".