From 9c2673d149b5eb5390ae7995da3613b68c35c4f4 Mon Sep 17 00:00:00 2001 From: Nathan Cutler Date: Fri, 19 Jun 2020 15:48:24 +0200 Subject: [PATCH] doc/SubmittingPatches-backports.rst: clarify backport PR labels Signed-off-by: Nathan Cutler --- SubmittingPatches-backports.rst | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/SubmittingPatches-backports.rst b/SubmittingPatches-backports.rst index 514d0f784dc61..b88d13ebdfb81 100644 --- a/SubmittingPatches-backports.rst +++ b/SubmittingPatches-backports.rst @@ -334,14 +334,19 @@ Once the backport PR is open, the first order of business is to set the Milestone tag to the stable release the backport PR is targeting. For example, if the PR is targeting "nautilus", set the Milestone tag to "nautilus". -If you don't have sufficient GitHub permissions to set the Milestone, add -a comment to the PR with the following content:: - - @ceph/backport-admins - -This will alert the `Stable Releases and Backports team`_ to your PR, and -someone will ensure your PR gets the proper labels. - +If you don't have sufficient GitHub permissions to set the Milestone, don't +worry. Members of the `Stable Releases and Backports team`_ periodically run +a script (``ceph-backport.sh --milestones``) which scans all PRs targetting stable +branches and automatically adds the correct Milestone tag if it is missing. + +Next, check which component label was applied to the master PR corresponding to +this backport, and double-check that that label is applied to the backport PR as +well. For example, if the master PR carries the component label "core", the +backport PR should also get that label. + +In general, it is the responsibility of the `Stable Releases and Backports +team`_ to ensure that backport PRs are properly labelled. If in doubt, just +leave the labelling to them. .. _`backport PR reviewing`: .. _`backport PR testing`: