regressions-github.rst (4989B)
1 Regressions from GitHub 2 ======================= 3 4 Release Management and the weekly regression triage must be aware of the 5 status of all reported regressions in order to assure we are not 6 shipping known regressions in Firefox releases. 7 8 If a team is using GitHub to manage their part of the Firefox project, 9 there’s a risk that those groups might not see a regression. 10 11 We need an agreed to standard for how we keep track of these. 12 13 Policy 14 ------ 15 16 *All Firefox components, even if their bugs are tracked off of Bugzilla, 17 must have a component in Bugzilla.* 18 19 *If a regression bug is found in any of the release trains (Nightly, 20 Beta, Release, or ESR) and the bug is in a Firefox component which uses 21 an external repository, the regression must be tracked by a bug in 22 Bugzilla (whether or not the component in question uses an external 23 issue tracker).* 24 25 *Unless approved by Release Management, any GitHub managed code with 26 open regressions will not be merged to mozilla-central. Even if the 27 regression is not code that has been previously merged into 28 mozilla-central.* 29 30 *All Firefox code managed in GitHub which uses GitHub to manage 31 issues* `must use the shared 32 tags <https://mozilla.github.io/bmo-harmony/labels>`__. 33 34 Comments 35 ~~~~~~~~ 36 37 The bug **must** have the regression keyword. 38 39 The bug **must** have release flags set. 40 41 If the team works in an external bug tracker, then the Bugzilla bug 42 **must** reference, using the see-also field, the URL of the bug in the 43 external tracker. 44 45 The bug **must not** be RESOLVED until the code from the external 46 repository containing the change set for the bug has landed in 47 mozilla-central. When the change set lands in mozilla-central, the 48 Bugzilla tracking bug should be set to RESOLVED FIXED and release status 49 flags should be updated to reflect the release trains the fix has been 50 landed or uplifted into. 51 52 If the change set containing the patch for the regression is reverted 53 from mozilla-central, for any reason, then the tracking bug for the 54 regression **must** be set to REOPENED and the release status flags 55 updated accordingly. 56 57 If the change set containing the patch for the bug is backed out, for 58 any reason, the bug must be reopened and the status flags on the 59 Bugzilla tracking bug updated. 60 61 The team responsible for the component with the regression **should** 62 strive to create a patch for mozilla-central which contains the fix for 63 the bug alone, not a monolithic patch containing changes for several 64 other bugs or features. 65 66 Landings of third-party libraries `must contain a manifest 67 file <https://docs.google.com/document/d/12ihxPXBo9zBBaU_pBsPrc_wNHds4Upr-PwFfiSHrbu8>`__. 68 69 Best Practices 70 -------------- 71 72 You must file a regression bug in Bugzilla 73 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 74 75 *If the code with the regression has landed in mozilla-central, you must 76 file a regression bug.* 77 78 Example 79 ^^^^^^^ 80 81 While using a release of Firefox (Nightly, Beta, Release, ESR) you run 82 across a bug. Upon research using MozRegression or other tools you find 83 that the bug was introduced in a change set imported from a component 84 whose code and issues are managed in GitHub. 85 86 Actions to take 87 ''''''''''''''' 88 89 - Open a new bug in Bugzilla in appropriate component and add the 90 REGRESSION keyword 91 - Set affected status for the releases where the bug appears 92 - Open an issue in the corresponding GitHub project, put the Bugzilla 93 bug number in the title with the prefix ‘Bug’ (i.e. “Bug 99999: 94 Regression in foo”) 95 - Add the REGRESSION label to the new issue 96 - Add the link to the GitHub issue into the ‘See Also” field in the 97 Bugzilla bug 98 99 Consequences 100 '''''''''''' 101 102 *Until the regression is fixed or backed out of the GitHub repo, the 103 project cannot merge code into mozilla-central* 104 105 Example 106 ^^^^^^^ 107 108 You import a development branch of a component managed in GitHub into 109 your copy of master. You find a bug and isolate it to the imported 110 branch. The code is managed in their own GitHub project, but bugs are 111 managed in Bugzilla. 112 113 Actions to take 114 ''''''''''''''' 115 116 - Open a new bug in Bugzilla in appropriate component and add the 117 REGRESSION keyword 118 - Set affected status for the releases where the bug appears 119 120 Consequences 121 '''''''''''' 122 123 *Until the regression is fixed or backed out of the GitHub repo, the 124 project cannot merge code into mozilla-central* 125 126 Do not file a regression bug in Bugzilla 127 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 128 129 *If the code with the regression has not landed in mozilla-central, you 130 do not need to file a bug.* 131 132 133 Example 134 ^^^^^^^ 135 136 You import a development branch of a component managed in GitHub into 137 your copy of master. You find a bug and isolate it to the imported 138 branch. The code and issues are managed in their own GitHub project. 139 140 141 Actions to take 142 ''''''''''''''' 143 144 - File new issue in the GitHub repository of the imported code. 145 - Label issue as REGRESSION 146 147 Consequence 148 ''''''''''' 149 150 *Issue blocks merge of GitHub project with mozilla-central until 151 resolved or backed out.*