From 07f1ef5656e0721282d01a8421eaca056348137d Mon Sep 17 00:00:00 2001 From: Dylan Baker Date: Wed, 11 Dec 2019 11:01:57 -0800 Subject: [PATCH] docs: Update stable process around using fixes: and gitlab Currently the docs still recommend using mesa-stable@lists.freedesktop.org, which is pretty awful. We really don't want a second mailing list and it's mostly full of junk because of CC: tags anyway. This changes the preferred actions to be: 1) use a fixes: tag ahead of time 2) use a Cc tag ahead of time if fixes isn't appropriate 3) Use a gitlab MR against the staging/ branch for post-merge/backport nominations Reviewed-by: Timothy Arceri Tested-by: Marge Bot Part-of: --- docs/submittingpatches.html | 58 +++++++++++++++++++------------------ 1 file changed, 30 insertions(+), 28 deletions(-) diff --git a/docs/submittingpatches.html b/docs/submittingpatches.html index 97fae5484a3..9113e417009 100644 --- a/docs/submittingpatches.html +++ b/docs/submittingpatches.html @@ -278,13 +278,14 @@ release.

  • By adding the Cc: mesa-stable@ tag as described below. -
  • Sending the commit ID (as seen in master branch) to the mesa-stable@ mailing list. -
  • Forwarding the patch from the mesa-dev@ mailing list. +
  • By adding the fixes: tag as described below. +
  • By submitting a merge requestion against the "staging/year.quarter" branch on gitlab.

-Note: resending patch identical to one on mesa-dev@ or one that differs only -by the extra mesa-stable@ tag is not recommended. +Please DO NOT send patches to +mesa-stable@lists.freedektop.org, it is not monitored actively and is a +historical artifact.

If you are not the author of the original patch, please Cc: them in your @@ -303,31 +304,27 @@ you should add an appropriate note to the commit message.

+Using a "fixes tag" as described in Patch formatting +is the prefered way to nominate a commit that you know ahead of time should be +backported. There are scripts that will figure out which releases to apply the +patch to automatically, so you don't need to figure it out. +

+ +

+Alternatively, you maye use a "CC:" tag. + Here are some examples of such a note: 

-CC: <mesa-stable@lists.freedesktop.org>
+CC: 20.0 19.3 <mesa-stable@lists.freedesktop.org>
-Simply adding the CC to the mesa-stable list address is adequate to nominate -the commit for all the active stable branches. If the commit is not applicable -for said branch the stable-release manager will reply stating so. - -This "CC" syntax for patch nomination will cause patches to automatically be -copied to the mesa-stable@ mailing list when you use "git send-email" to send -patches to the mesa-dev@ mailing list. If you prefer using --suppress-cc that -won't have any negative effect on the patch nomination. -

-Note: by removing the tag [as the commit is pushed] the patch is -explicitly rejected from inclusion in the stable branch(es). -Thus, drop the line only if you want to cancel the nomination. +Using the CC tag should include the stable branches you want +to nominate the patch to. If you do not provide any version it is nominated to +all active stable branches.

-Alternatively, if one uses the "Fixes" tag as described in the "Patch formatting" -section, it nominates a commit for all active stable branches that include the -commit that is referred to. -

Criteria for accepting patches to the stable branch

Mesa has a designated release manager for each stable branch, and the release @@ -387,16 +384,21 @@ yourself warned.

Sending backports for the stable branch

-By default merge conflicts are resolved by the stable-release manager. In which -case he/she should provide a comment about the changes required, alongside the -Conflicts section. Summary of which will be provided in the -pre-release announcement. +By default merge conflicts are resolved by the stable-release manager. The +release maintainer should resolve trivial conflicts, but for complex conflicts +should ask the original author to provide a backport of de-nominate.

-Developers are interested in sending backports are recommended to use either a -[BACKPORT #branch] subject prefix or provides similar information -within the commit summary. +For patches that either need to be nominated after they've landed in master, or +that are known ahead of time to not not apply cleanly to a stable branch (such +as due to a rename), using a gitlab MR is most appropirate. + +The MR should be based on and target the staging/year.quarter branch, not on +the year.quarter branch, per the stable branch policy. + +Assinging the MR to release maintainer for said branch or mentioning them is +helpful, but not required.

Git tips