Signed-off-by: Nicolas Morey-Chaisemartin <NMoreyChaisemartin@xxxxxxxx> --- Documentation/stable.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/Documentation/stable.md b/Documentation/stable.md index d7ea9822..d3eb90f5 100644 --- a/Documentation/stable.md +++ b/Documentation/stable.md @@ -56,10 +56,27 @@ You must note the upstream commit ID in the changelog of your submission, Option 1 is strongly preferred, is the easiest and most common. Option 2 and Option 3 are more useful if the patch isn’t deemed worthy at the time it is applied to a public git tree (for instance, because it deserves more regression testing first). -Option 3 is especially useful if the patch needs some special handling to apply to an older version. +Option 3 is especially usefu if the patch needs some special handling to apply to an older version. Note that for Option 3, if the patch deviates from the original upstream patch (for example because it had to be backported) this must be very clearly documented and justified in the patch description. ## Versioning See versioning.md for setting package version on a stable branch. + + +## Creating a stable branch + +Stable branch should be created from a release tag of the master branch. +The first thing to do on a master branch is to commit the mainstream release ABI infos +so that latters patches/fixes can be checked against this reference. + +To do that, the creator of the branch should run +``` +./buildlib/gen-abi +mv build-abi/ABI buildlib/ABI +git add buildlib/ABI +git commit +``` + +Note that the ABI must NOT be committed at any point in the master branch. -- 2.15.0.168.g9a51f1b30.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
