Confirm
229
edits
Changes
Added criteria discussed during relman SF '18 work week
As described in [[Security/Bug_Approval_Process]]
If the bug whiteboard contains a deadline, the uplift should be granted only after this date.
=Uplift review criteria/best practices=
* Size of change, patch
* Which component is this fix in?
** Low risk: CSS, front-end, build system
** Medium risk: Telemetry (adding probes on hot path is perf risk) or changing the data collection
** High risk: Graphics, layout, printing, DOM, JS, Performance related changes (56% caused regressions), Mem allocator, GCs, Search defaults
* Lots of discussion in comments - be more cautious
* Lots of patch review attempts - be more cautious
* Test status
** Verification on previous channels helps!
* QA verification
* Timing of uplift during beta cycle
** Uplifts during late cycle need more caution
** Uplifts early in the cycle can afford the luxury of less scrutiny
** For RC week and the week before, consider only dot release worthy uplifts
** Be cautious with trivial ride-alongs
* Automated tests
** More automated tests the better
* Code coverage
** TBD
* Crash, memleaks, hangs, perf fixes
** High volume crash fixes and fixes that are verified from other channels helps
** Due to high impact, these need more scrutiny
* Data collection changes
** Mandate data-review (might use Phabricator commit hook / subscription for that)
* Localization (l10n) changes
** Loop in l10n team for their review
** Changes would include new strings
* In Quantum, we used second review from eng mngr during RC week
[[category:Release_Management|U]]
[[Category:Release_Management:Processes|Uplift]]
