|
@@ -371,6 +371,37 @@ in the following cases:
|
|
|
* whenever you feel it will help presenting your work, your choices,
|
|
|
the review process, etc.
|
|
|
|
|
|
+==== Patches for maintenance branches
|
|
|
+
|
|
|
+When fixing bugs on a maintenance branch, bugs should be fixed on the
|
|
|
+master branch first. The commit log for such a patch may then contain a
|
|
|
+post-commit note specifying what branches are affected:
|
|
|
+
|
|
|
+----
|
|
|
+package/foo: fix stuff
|
|
|
+
|
|
|
+Signed-off-by: Your Real Name <your@email.address>
|
|
|
+---
|
|
|
+Backport to: 2020.02.x, 2020.05.x
|
|
|
+(2020.08.x not affected as the version was bumped)
|
|
|
+----
|
|
|
+
|
|
|
+Those changes will then be backported by a maintainer to the affected
|
|
|
+branches.
|
|
|
+
|
|
|
+However, some bugs may apply only to a specific release, for example
|
|
|
+because it is using an older version of a package. In that case, patches
|
|
|
+should be based off the maintenance branch, and the patch subject prefix
|
|
|
+must include the maintenance branch name (for example "[PATCH 2020.02.x]").
|
|
|
+This can be done with the +git format-patch+ flag +--subject-prefix+:
|
|
|
+
|
|
|
+---------------------
|
|
|
+$ git format-patch --subject-prefix "PATCH 2020.02.x" \
|
|
|
+ -M -s -o outgoing origin/2020.02.x
|
|
|
+---------------------
|
|
|
+
|
|
|
+Then send the patches with +git send-email+, as described above.
|
|
|
+
|
|
|
==== Patch revision changelog
|
|
|
|
|
|
When improvements are requested, the new revision of each commit
|