Changes

Jump to: navigation, search

Release Management/ESR Landing Process

12 bytes added, 23:26, 9 November 2015
m
adding missing close-parens
1) When an engineer believes that a stability bug needs to be addressed for the ESR, or a security fix that's landed on a branch affects the ESR:
* Set '''tracking-firefox-esr{{ESR_CURRENT}}''' (and if we're in the middle of supporting 2 versions, then also tracking-firefox-esr{{ESR_NEXT}} ) to '''?'''* Set '''status-firefox-esr{{ESR_CURRENT}}''' (and if we're in the middle of supporting 2 versions, then also status-firefox-esr{{ESR_NEXT}} ) to '''affected''' if an ESR patch is still being worked on* Set '''approval-mozilla-esr{{ESR_CURRENT}}''' (and if we're in the middle of support 2 versions, then also approval-mozilla-esr{{ESR_NEXT}} ) to '''?''' and '''status-firefox-esr{{ESR_CURRENT}}/{{ESR_NEXT}}''' to ''' checkin-pending ''' if a patch is ''ready to land on mozilla-esr{{ESR_CURRENT}}/{{ESR_NEXT}}''
2) Members of both Security and Release Management teams will triage tracking-firefox-esr{{ESR_CURRENT}}/{{ESR_NEXT}}=?, and if agreement is that it's needed for the ESR, the tracking flag will be set to the first version of mainline Firefox that the patch is present in and the '''approval-mozilla-esr{{ESR_CURRENT}}/{{ESR_NEXT}}''' flag will be set to '''+'''.
* In the case of an ESR-specific regression, we'll track for the next ESR release (e.g.: {{ESR_FUTURE}}).
Canmove, confirm
629
edits

Navigation menu