Add doc file to detail the stable- process: release, submission. Signed-off-by: Nicolas Morey-Chaisemartin <NMoreyChaisemartin@xxxxxxxx> --- The nice version without markup can be seen here: https://github.com/nmorey/rdma-core/blob/dev/master/stable-guide/Documentation/stable.md Documentation/stable.md | 64 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 Documentation/stable.md diff --git a/Documentation/stable.md b/Documentation/stable.md new file mode 100644 index 00000000..b9405848 --- /dev/null +++ b/Documentation/stable.md @@ -0,0 +1,64 @@ +# Stable Branch Release + + +## General + +Current Maintainer: Nicolas Morey-Chaisemartin <NMoreyChaisemartin@xxxxxxx> + +Upstream rdma-core is considered stable after each mainline release. +Branched stable releases, off a mainline release, are on as-needed basis and limited to bug fixes only. + +All bug fixes are to be backported from mainline and applied by stable branch maintainer. + +Branched stable releases will append an additional release number (e.g. 15.1) and will ensure that Travis CI reports a successful build. + +Regular stable releases will be generated at the same time as mainline releases. +Additional stable releases can be generated if the need arise (Needed by distributions or OFED). + +## Patch Rules + + * It must be obviously correct and tested. + * It cannot be bigger than 100 lines, with context. + * It must fix only one thing. + * It must fix a real bug that bothers people (not a, “This could be a problem...� type thing). + +## Submitting to the stable branch + +Submissions to the stable branch follow the same process as [kernel-stable](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-kernel-rules.rst). + +### Option 1 + +Patches sent to master should add the tag: + + `Cc: stable@xxxxxxxxxxxxxx` + +in the sign-off area. Once the patch is merged, it will be applied to the stable tree +without anything else needing to be done by the author or subsystem maintainer. + +If the patch should be applied to more than one release, add the info version as such: + + `Cc: stable@xxxxxxxxxxxxxx # v15.1 v14` + + +### Option 2 + +After the patch has been merged to master, send an email to +stable@xxxxxxxxxxxxxx containing the subject of the patch, the commit ID, +why you think it should be applied, and what rdma-core version you wish it to +be applied to. + +### Option 3 + +Send the patch, after verifying that it follows the above rules, to stable@xxxxxxxxxxxxxx. +You must note the upstream commit ID in the changelog of your submission, + as well as the rdma-core version you wish it to be applied to. + +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. + +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. \ No newline at end of file -- 2.15.0.169.g3d3eebb67.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
