-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
DOC: clarify the milestoning and backport policy wording #25652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
doc/devel/coding_guide.rst
Outdated
Setting a milestone does not imply or guarantee that a PR will be merged for that | ||
release, but if it were to be merged what release it would be in. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know you didn't touch this in this PR, but maybe uninverting the sentence will make it clearer? Something like (and I admit document is probably the wrong word here)
Setting a milestone does not imply or guarantee that a PR will be merged for that | |
release, but if it were to be merged what release it would be in. | |
Setting a milestone documents which release a PR targets but does not imply or guarantee that the PR will be merged for that release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion:
The milestone marks the release a PR should go into. It is an intent but can be changed because of re-evaluation of the PR scope and maturity or release planning.
doc/devel/coding_guide.rst
Outdated
Setting a milestone does not imply or guarantee that a PR will be merged for that | ||
release, but if it were to be merged what release it would be in. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion:
The milestone marks the release a PR should go into. It is an intent but can be changed because of re-evaluation of the PR scope and maturity or release planning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @tacaswell this seems much clearer to me. I just have one point that I’m still not quite clear on. Sorry if I’m being overly pedantic!
doc/devel/coding_guide.rst
Outdated
Other changes, such as regressions against older releases or api | ||
inconsistencies the user can work around in their code, are on a case-by-case | ||
basis, should be low-risk, and need someone to advocate for and shepherd | ||
through the backport. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This bit about advocating for a backport is not something I’ve observed in the admittedly short time I’ve been here. I think we more often state why we’re not backporting something.
c7f44a6
to
e89213e
Compare
|
||
* *Documentation changes* (all .rst files and examples) are milestoned | ||
``v3.N-doc``. | ||
* *Documentation changes* (all .rst files and examples) may be milestoned |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* *Documentation changes* (all .rst files and examples) may be milestoned | |
* *Documentation changes* (only .rst files and examples) may be milestoned |
- critical bug fixes (segfault, failure to import, things that the | ||
user can not work around) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- critical bug fixes (segfault, failure to import, things that the | |
user can not work around) | |
- critical bug fixes (segfault, failure to import, things that the | |
user cannot work around) |
inconsistencies the user can work around in their code) are on a | ||
case-by-case basis, should be low-risk, and need someone to advocate | ||
for and shepherd through the backport. | ||
and may attempt to backport regressions introduced in older releases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and may attempt to backport regressions introduced in older releases. | |
and may attempt to backport fixes for regressions introduced in older releases. |
Cycling in hope of picking up #25672… |
Well that didn’t work. @tacaswell would you mind rebasing? |
- make less prescriptive - fix formatting (the milestone guidelines were in a nested list?) - minor wording tweaks closes matplotlib#25649 Co-authored-by: Jody Klymak <jklymak@gmail.com> Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
e89213e
to
fedddea
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Grammar/wording suggestions, but since there are two reviews already I can make the changes in a follow up PR.
- fixes for regressions against the last two releases. | ||
- critical bug fixes (segfault, failure to import, things that the | ||
user can not work around) | ||
- fixes for regressions introduced in last two minor releases |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- fixes for regressions introduced in last two minor releases | |
- fixes for regressions introduced in the last two minor releases |
effort and risk of re-implementing the bug fix vs the severity of the bug. | ||
When in doubt, err on the side of not backporting. | ||
|
||
When backporting a Pull Request fails or is declined re-milestone the original |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When backporting a Pull Request fails or is declined re-milestone the original | |
When backporting a Pull Request fails or is declined, re-milestone the original |
are changes to :file:`doc`, :file:`examples`, or :file:`tutorials`. | ||
Any changes to :file:`lib` or :file:`src` including docstring-only changes | ||
should not be backported to this branch. | ||
are changes to :file:`doc`, :file:`examples`, or :file:`tutorials`. Any |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are changes to :file:`doc`, :file:`examples`, or :file:`tutorials`. Any | |
are changes to :file:`doc`, :file:`examples`, :file:`tutorials` or :file:`galleries` Any |
The milestone marks the release a PR should go into. It is an intent but can | ||
be changed because of re-evaluation of the PR scope and maturity or release | ||
planning. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The milestone marks the release a PR should go into. It is an intent but can | |
be changed because of re-evaluation of the PR scope and maturity or release | |
planning. | |
The milestone marks the release a PR should go into. It states intent, but can | |
be changed because of release planning or re-evaluation of the PR scope and maturity. |
I think merging here and opening a follow-up PR for further wording tweaks is a good plan. |
Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
closes #25649