Sheriffing/How To/Uplifts: Difference between revisions

← Older edit

Sheriffing/How To/Uplifts (view source)

Revision as of 13:33, 26 October 2020

1,895 bytes added , 26 October 2020

→‎Bug Queries: the "custom date range" checkbox is gone from the release tracking report

Julien Cristau

287

edits

@@ Line 4: / Line 4: @@
 = Bug Queries =
 The [https://bugzilla.mozilla.org/page.cgi?id=release_tracking_report.html Release Tracking Report] has bug queries which can find the bugs which needed to be uplift to mozilla-beta or mozilla-release. However, it has limitations in that it only sees bugs that have a status of "affected", "fixed", or "verified" set. As a result, it will miss approved bugs if no status is set ("---") and will show bugs as still needing uplift if their status is an unexpected value (like "disabled").
+Bugs which don't need approval to get uplifted because they don't modify the build - e.g. test fixes - have the string '''checkin-needed-beta''' in the whiteboard and can be listed with [https://bugzilla.mozilla.org/buglist.cgi?f1=status_whiteboard&o1=substring&query_format=advanced&v1=checkin-needed-beta&list_id=15466087 this query].
 Filter the bugs, using the following steps (example for mozilla-beta):
 * Set the dropdown with "approval-mozilla-*" to "'''approval-mozilla-beta'''".
 * The status dropdown has to be changed from "?" (approval requested) to "+" (approval granted).
-* Use the checkbox to set a custom date range in which the approval was granted. Usually the last week is sufficient, only when something got approved and backed out later and the update of the patch with the fix takes longer than usual, a longer time frame will be needed. To check the whole date range for that release cycle, start with the last merge date from the [[RapidRelease/Calendar|release calendar]].
+* Set a date range in which the approval was granted. Usually the last week is sufficient, only when something got approved and backed out later and the update of the patch with the fix takes longer than usual, a longer time frame will be needed. To check the whole date range for that release cycle, start with the last merge date from the [[RapidRelease/Calendar|release calendar]].
 * Set the status '''status-firefoxNN''' to '''not fixed''' - NN is the version number used for beta: 1 less than the version number on Nightly. Check the [[RapidRelease/Calendar|release calendar]] to find the version number for the current beta version. Same version number for beta and release.
 * Run the search.
+[[File:Sheriffing uplift query.jpg]]
 The query will return the list of bugs needing uplift.
-[[File:Sheriffing uplift query.jpg]]
+To prevent unnecessary conflicts during the uplift process, the bugs and their patches shall be uplifted in the order like they landed on the tree from which they are grafted. For mozilla-beta that is from mozilla-central and can be achieved like this:
+# Go to the bottom of the list with bugs pending uplift.
+# Click 'Change Columns'.
+# In the left list of 'Available Columns', find 'Closed' (= last time the bug got set to 'RESOLVED').
+# Move it to the right list of 'Selected Columns' and save it.
+# '''Sort''' the bug list by '''Closed'''.
+# Uplift the bugs which landed on mozilla-central.
+#* Check what attachments have approval-mozilla-beta+
+#* Check if attachments are written for beta and haven't landed on mozilla-central: They will have 'beta' or similar in the attachment name.
+#* Find the comment in which the developer requested the uplift.
+#*# Check the attachment for which the request was made (at the top of the request).
+#*# Scan the request for other bugs which have to land together with this one.
+#*# Read the response of the release manager for any clarifications what needs to be done.
+#* If a patch landed on central and is also need for beta, use <code>hg graft -r revision</code>
+#* If it's a patch written for beta, import it with Phabricator. If it's a plain text patch, use <code>hg import linktopatch</code>.
+# Bugs not yet resolved should be managed after the resolved ones.
+#* If they are supposed to land on mozilla-central and haven't done so yet, skip the uplift until they did unless there are specific instructions to do otherwise.
 == ESR ==
 The ESR intermittent queries are *very* useful for looking at recently-fixed intermittent failure bugs and ensuring that status flags are set for all applicable releases. The [https://wiki.mozilla.org/RapidRelease/Calendar Release Calendar] can help determine in which release an intermittent first appeared (in addition to looking at Treeherderbot comments in the bug).
-<b>ESR60: </b>[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;field0-0-0=flagtypes.name;type0-0-0=equals;value0-0-0=approval-mozilla-esr60%2B;field0-1-0=cf_status_firefox_esr60;type0-1-0=nowordssubstr;value0-1-0=fixed%20verified%20wontfix%20unaffected%20disabled All esr60 approvals not yet uplifted]
+'''ESR60''': [https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=esr60-approval%2B&sharer_id=258347 All esr60 approvals not yet uplifted]
+'''ESR68''': [https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=esr68-approval%2B&sharer_id=258347 All esr68 approvals not yet uplifted]
 = Prerequisites =