jiuyuan
/
test_ok1
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Merge pull request #7766 from nicoddemus/backporting-docs 

Add guidelines section about backporting
This commit is contained in:
Ran Benita 2020-09-19 21:18:41 +03:00 committed by GitHub
parent 4e460cdd9e 895a8cf296
commit 9f164b7227
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
CONTRIBUTING.rst
View File

@ -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
-------------------------