From 895a8cf2969fa66c5167eaa68453771768c472b0 Mon Sep 17 00:00:00 2001 From: Bruno Oliveira Date: Thu, 17 Sep 2020 10:06:04 -0300 Subject: [PATCH] Add guidelines section about backporting From https://github.com/pytest-dev/pytest/pull/7723#issuecomment-693310439 --- CONTRIBUTING.rst | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index e4a3e7c14..48ba147b7 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -406,6 +406,27 @@ actual latest release). The procedure for this is: * Delete the PR body, it usually contains a duplicate commit message. +Who does the backporting +~~~~~~~~~~~~~~~~~~~~~~~~ + +As mentioned above, bugs should first be fixed on ``master`` (except in rare occasions +that a bug only happens in a previous release). So who should do the backport procedure described +above? + +1. If the bug was fixed by a core developer, it is the main responsibility of that core developer + to do the backport. +2. However, often the merge is done by another maintainer, in which case it is nice of them to + do the backport procedure if they have the time. +3. For bugs submitted by non-maintainers, it is expected that a core developer will to do + the backport, normally the one that merged the PR on ``master``. +4. If a non-maintainers notices a bug which is fixed on ``master`` but has not been backported + (due to maintainers forgetting to apply the *needs backport* label, or just plain missing it), + they are also welcome to open a PR with the backport. The procedure is simple and really + helps with the maintenance of the project. + +All the above are not rules, but merely some guidelines/suggestions on what we should expect +about backports. + Handling stale issues/PRs -------------------------