Release Management/Release Process: Difference between revisions

Release Management/Release Process (view source)

211 bytes added , 28 February 2022

→‎The Process: added duplicate bug scenario

255

edits

Revision as of 21:52, 28 October 2020 (view source) Bjherbison (talk \| contribs) (→‎Release timeline: Not always four weeks) ← Older edit		Revision as of 14:56, 28 February 2022 (view source) Diannasmith (talk \| contribs) (→‎The Process: added duplicate bug scenario) Newer edit →
Line 112:		Line 112:

	3) Once you nominated a patch with '''approval-mozilla-beta/release: ?''' we will evaluate the information given in the attachment request we may either approve/deny/request more information. Once you get an approval , i.e '''approval-mozilla-beta/release: +''', sheriffs or release managers will land it on the corresponding branch and mark '''status-Firefox XX''' flag to ''fixed'', making sure [https://treeherder.mozilla.org/ Treeherder] is green.		3) Once you nominated a patch with '''approval-mozilla-beta/release: ?''' we will evaluate the information given in the attachment request we may either approve/deny/request more information. Once you get an approval , i.e '''approval-mozilla-beta/release: +''', sheriffs or release managers will land it on the corresponding branch and mark '''status-Firefox XX''' flag to ''fixed'', making sure [https://treeherder.mozilla.org/ Treeherder] is green.

			'''Note:''' In the case that a tracked bug is resolved as a duplicate bug, it is best practice for the release management team to remove the tracking flag from the duplicate bug, and add it to the active bug.