Discussion points

Could we have foreseen every new blocking bug and/or the bug that caused the respin? How can we not get blindsided in the future?

Did we make the right call keeping 3.5.10 and 3.6.4 tied together?

Did the "project branch → opt-in beta → beta → release" format work well? How might we do it differently/better?

How can schedule be better communicated when things are in flux?

Is socorro at a state we are confident with? Are there more changes that need to be made? Are there future projects that may have the same sort of issues?

Do we need an action plan for dealing with 3rd parties? How long are we expected to wait? Should we have a more formal outreach/partner program?

What sort of things might we backport in the future? Are the lessons here specific to OOPP or can they be applied generally?

clear mails (with correct subjects) on rel-drivers for record keeping

not everyone reads never-ending scrollback

easy to miss an important handoff if not reply-all, with changed subject

hard to figure out historical

problems tracking patches across branches

bsmedberg reported problems tracking fixes on lorentz to m-c and then to moz192 and relbranch

nthomas caught missed fix on relbranch with build#2

any way to avoid one patch per respin?

Metrics can work on Operational Metrics dashboards for systems that have complex interactions or systems that can be monitored for the trending affect of things such as a config change or a release. See [[1]]

Things that went right

Things that went wrong

Suggested improvements

Release codenames to reduce confusion (?) (clegnitto)

Branch landing verifier scripts (clegnitto)

Need to not use IRC and meetings, need a written record

Emails to release-drivers should have clear subjects with the version # and not be threaded

Date-scoped queries for historical mining of bug state

Need better defined/more formal beta program and feedback channels

Create alternate plans at the beginning and add firebreaks with mitigation plans

Use a rage for certain schedule items (shipping in particular), to give some wiggleroom and prevent excessive schedule churn

Would be useful for RelEng to have SLAs so that release drivers can set expectations/urgency for each build. The information can also be looked at in post-mortems as well