Release Management/Release Process/FAQ
Contents
- 1 Frequently Asked Questions
- 1.1 Q) Do I need to have a tracking flag set on every bug that may have to land on a firefox channnel ?
- 1.2 Q) How do I know what versions of Firefox are affected by a bug ?
- 1.3 Q) When would I have to backout a patch ?
- 1.4 Q) Dealing with unexpected failures on Treeherder ?
- 1.5 Q) How many beta's do we have per Firefox Release cycle ?
- 1.6 Q) Can I wait till the last beta to get my patch landed ?
- 1.7 Q) Am I allowed to make string changes on branches ?
- 1.8 Q) I found a bug which may be a regression, what do I do ?
- 1.9 Q) What criteria is typically used for tracking a bug ?
- 1.10 Q) What kind of changes are OK to make on what branches ?
- 1.11 Q) Is there an easy I could implement channel specific features that may be categorized as new/experimental/may not be ready for release ?
Frequently Asked Questions
Q) Do I need to have a tracking flag set on every bug that may have to land on a firefox channnel ?
A) NO. This is often a common misconception among people flagging bugs for tracking.You could go ahead and request approval for landing on any branch even if the bug is not currently tracked.Based on where we are in our current risk cycle, the user impact your patch may have,keeping in mind areas of regression , other risk considerations we will either grant/deny or request more information for uplift.
Q) How do I know what versions of Firefox are affected by a bug ?
Status flags are the best way to see any recently affected Firefox versions.If unmarked and a regression getting the regression-window would be the best way to help understand the bug that regressed this and in turn determining what versions are affected.If its a new feature blocker then the version the new feature launches will be affected.
Q) When would I have to backout a patch ?
All changes must meet the general checkin rules. You must check the tree before pushing, and watch the tree for failures after pushing.You may have to backout based on any new test failures your patch caused or if we identify a new regression which is critical for us to solve and there is risk in taking a forward fix based on where we are in thee current release cycle we may request a backout
Q) Dealing with unexpected failures on Treeherder ?
Check this page for more info
Q) How many beta's do we have per Firefox Release cycle ?
In a traditional cycle you can expect six beta's per cycle. But we may sometimes spin additional beta's if needed for any critical change that may be necessitating further betas.
Q) Can I wait till the last beta to get my patch landed ?
Please don't . The higher the beta number the more riskier would it be to land the patch . Note it will also lose on beta testing time which your patch may get if landed early. After Fx130 beta 4 goes to build, we prefer to only take the most critical bugs and hence keep sending you reminders by Release Management Nag emails to land your patches in a timely manner .
Q) Am I allowed to make string changes on branches ?
All repositories except mozilla-central are string frozen which means we do not allow any string changes on aurora/beta/release channels including "string removals". This gives localizers enough time to help localize the new/modified strings in the next few weeks while there are no changes coming in to the existing strings.
Q) I found a bug which may be a regression, what do I do ?
Add the ‘regression’ keyword, as always. Set the tracking-firefoxX : ?. If you know the branches(aurora/beta/release) the bug affects set the status flags accordingly . If you don’t know what branches are affected, add the regressionwindow-wanted, keyword
Q) What criteria is typically used for tracking a bug ?
Below example can be used as guidelines before nominating a Bug for tracking :
- The bug fixes a (new or existing) top crash
- The bug causes or is a top crash
- The bug has the potential to impact web compatibility
- The bug is a recent regression from current release or from a feature that was shipped recently
- The bug has add-on compatibility implications release drivers should be aware of
- The bug introduced a new feature which may need to be backed out if feedback is negative
- The bug is requesting a feature backout on mozilla-aurora or mozilla-beta
If nominated without any obvious implications Release Management will always request for more justification if it does not meet our tracking criteria before we go ahead and track the bug for a release cycle .
Q) What kind of changes are OK to make on what branches ?
OK
As a general rule please keep in mind the earlier we land any Bugs in a given cycle, the more opportunity you have to get the fix well tested .Hence whenever we are the end of cycle we always take Bugs that are absolutely needed and a critical for release especially for Beta keeping in mind the risk of fallout vs the reward here.
- Fixes for tracked bugs on aurora/beta
- Fixes for top-crashes
- Fixes for regressions
- Backouts if the investigation leads its a better alternative if forward fixes are risky depending on how close we are to the end of cycle.
- Any low risk uplifts for bugs that are not tracked but may help improve our product
- Landing tests that may help a feature with no impact to existing test framework
- Fixes for intermittent oranges if low risk
- Anything that is absolutely needed and may not be part of the build(NPOTB)
- It is OK to land any patch with IDL changes needed for your code but make sure to the rev the needed IID to avoid addon compat issues before Beta 1 goes to build
NOT OK
- Landing a whole new feature directly for Beta . This may include turning pref-on by default for a feature or uplifting a lot of code right before Beta 1 goes to build.
- Making any major architectural changes to your code while its on Beta
- Any patch that is not well tested or baked enough for it to be uplifted
- Patches that may include string changes/removals will not be approved on aurora or beta
- Any patch that may has an IDL change and may impact addon compatibility is not allowed post Beta 1
Q) Is there an easy I could implement channel specific features that may be categorized as new/experimental/may not be ready for release ?
We have recently been helped by Gavin Sharp to be able to have Channel-specific build defines which helps control the feature per channels in a better way and may fit the use case here. Check wiki on implementation details . This really helps in cases where features that require going to aurora/beta to gather impact before ship, but not ready for immediate release to be configurable