workflow enhancement: a `mark bug as fixed` PR tag [feature request]
We've got the automerge tag on GH, it+bot make it awesome. There's one more thing I'd like to see that could help with bug hygiene: A tag to close the associated bug as "fixed" after the merge happens.
This doesn't have to be tied to automerge; in practice you'd find them used in unison somewhat often. More readily on features done on the main branch rather than bug fixes needing backports to multiple releases.
We've had such a system at work for so long I don't even remember when it was added, but it has been a great time saver. Less more bugs laying around fixed but not marked as such. Less need for triagers to manually ask someone who has the permissions to change the bug state. Less unintentionally still open bugs in the way distracting people. Good all around.
It isn't the primary way to close issues, but it helps in situations where it makes sense. I'd assume the same set of people allowed to add automerge should be allowed to add this label.
-gps
Once issues move to GitHub we’ll have this with no additional effort.
On Sun, Oct 11, 2020 at 12:14 Gregory P. Smith <greg@krypto.org> wrote:
We've got the automerge tag on GH, it+bot make it awesome. There's one more thing I'd like to see that could help with bug hygiene: A tag to close the associated bug as "fixed" after the merge happens.
This doesn't have to be tied to automerge; in practice you'd find them used in unison somewhat often. More readily on features done on the main branch rather than bug fixes needing backports to multiple releases.
We've had such a system at work for so long I don't even remember when it was added, but it has been a great time saver. Less more bugs laying around fixed but not marked as such. Less need for triagers to manually ask someone who has the permissions to change the bug state. Less unintentionally still open bugs in the way distracting people. Good all around.
It isn't the primary way to close issues, but it helps in situations where it makes sense. I'd assume the same set of people allowed to add automerge should be allowed to add this label.
-gps
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/R... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- --Guido (mobile)
GitHub workflow is nice when a single commit is enough to close an issue. But what if a bug should be fixed in multiple branches? Is there a way in GitHub to require one commit per branch to close an issue?
Victor
Le dim. 11 oct. 2020 à 21:16, Guido van Rossum <guido@python.org> a écrit :
Once issues move to GitHub we’ll have this with no additional effort.
On Sun, Oct 11, 2020 at 12:14 Gregory P. Smith <greg@krypto.org> wrote:
We've got the automerge tag on GH, it+bot make it awesome. There's one more thing I'd like to see that could help with bug hygiene: A tag to close the associated bug as "fixed" after the merge happens.
This doesn't have to be tied to automerge; in practice you'd find them used in unison somewhat often. More readily on features done on the main branch rather than bug fixes needing backports to multiple releases.
We've had such a system at work for so long I don't even remember when it was added, but it has been a great time saver. Less more bugs laying around fixed but not marked as such. Less need for triagers to manually ask someone who has the permissions to change the bug state. Less unintentionally still open bugs in the way distracting people. Good all around.
It isn't the primary way to close issues, but it helps in situations where it makes sense. I'd assume the same set of people allowed to add automerge should be allowed to add this label.
-gps
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/R... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- --Guido (mobile)
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/A... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
On Sun, Oct 11, 2020 at 2:58 PM Victor Stinner <vstinner@python.org> wrote:
GitHub workflow is nice when a single commit is enough to close an issue. But what if a bug should be fixed in multiple branches? Is there a way in GitHub to require one commit per branch to close an issue?
I wasn't worried about automating that case... But it is something we do reasonably often for bug fixes (merge the PR to main plus PRs to backport to the past two releases) so it'd be a natural next step. It may be more difficult to automate and express as it becomes a logical "x and y and z -> close/fixed" concept.
If you predicate this automation on having switched to github issues, Those work differently than bpo. We could choose to always "close" after an issue is fixed in the first branch (usually main; though we occasionally have issues that are release-only and don't impact main) and use tags on issues to determine when they still need backports to past releases. The Issue's "open for backport to 3.9" tag being removed once the fixes land in the relevant release branch.
That gets complicated, I'd leave that up to whomever designs and implements our GH Issues workflow (PEP-581 and 588 or otherwise).
-gps
Victor
Le dim. 11 oct. 2020 à 21:16, Guido van Rossum <guido@python.org> a écrit :
Once issues move to GitHub we’ll have this with no additional effort.
On Sun, Oct 11, 2020 at 12:14 Gregory P. Smith <greg@krypto.org> wrote:
We've got the automerge tag on GH, it+bot make it awesome. There's one
more thing I'd like to see that could help with bug hygiene: A tag to close the associated bug as "fixed" after the merge happens.
This doesn't have to be tied to automerge; in practice you'd find them
used in unison somewhat often. More readily on features done on the main branch rather than bug fixes needing backports to multiple releases.
We've had such a system at work for so long I don't even remember when
it was added, but it has been a great time saver. Less more bugs laying around fixed but not marked as such. Less need for triagers to manually ask someone who has the permissions to change the bug state. Less unintentionally still open bugs in the way distracting people. Good all around.
It isn't the primary way to close issues, but it helps in situations
where it makes sense. I'd assume the same set of people allowed to add automerge should be allowed to add this label.
-gps
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/R...
Code of Conduct: https://www.python.org/psf/codeofconduct/
-- --Guido (mobile)
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/A... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
On Sun, Oct 11, 2020 at 10:14 PM Gregory P. Smith <greg@krypto.org> wrote:
We've got the automerge tag on GH, it+bot make it awesome. There's one more thing I'd like to see that could help with bug hygiene: A tag to close the associated bug as "fixed" after the merge happens.
You can already do that by adding "(Fixes|Closes) bpo-NNN" to the commit message.
--Berker
On Sun, Oct 11, 2020 at 4:23 PM Berker Peksağ <berker.peksag@gmail.com> wrote:
On Sun, Oct 11, 2020 at 10:14 PM Gregory P. Smith <greg@krypto.org> wrote:
We've got the automerge tag on GH, it+bot make it awesome. There's one
more thing I'd like to see that could help with bug hygiene: A tag to close the associated bug as "fixed" after the merge happens.
You can already do that by adding "(Fixes|Closes) bpo-NNN" to the commit message.
Oh cool! where do I put that so that the message automerge generates sees it?
--Berker
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/T... Code of Conduct: https://www.python.org/psf/codeofconduct/
On Sun, Oct 11, 2020 at 10:13 PM Gregory P. Smith <greg@krypto.org> wrote:
We've got the automerge tag on GH, it+bot make it awesome. There's one more thing I'd like to see that could help with bug hygiene: A tag to close the associated bug as "fixed" after the merge happens.
This doesn't have to be tied to automerge; in practice you'd find them used in unison somewhat often. More readily on features done on the main branch rather than bug fixes needing backports to multiple releases.
We've had such a system at work for so long I don't even remember when it was added, but it has been a great time saver. Less more bugs laying around fixed but not marked as such. Less need for triagers to manually ask someone who has the permissions to change the bug state. Less unintentionally still open bugs in the way distracting people. Good all around.
It isn't the primary way to close issues, but it helps in situations where it makes sense. I'd assume the same set of people allowed to add automerge should be allowed to add this label.
I've been taking advantage of the need to go to the bpo issue to close it for two things:
- Final review of the issue, making sure there isn't anything else that came up in its comments that warrants further attention.
- Thanking the reporter, patch/PR submitters and others who contributed.
I've come to think that #2 is especially important. This is a difference with a project like ours vs. a work environment: At a workplace, there usually isn't a need to thank people for their work on an issue, so just making sure that status is updated is enough.
Therefore, I'd only use such a feature to close issues I opened myself when merging my own PRs which resolve them.
- Tal
Le lun. 12 oct. 2020 à 08:56, Tal Einat <taleinat@gmail.com> a écrit :
I've come to think that #2 is especially important. This is a difference with a project like ours vs. a work environment: At a workplace, there usually isn't a need to thank people for their work on an issue, so just making sure that status is updated is enough.
You're right, I'm trying to always thank the reporter, the dev who fixed it, but also everyone who helped to investigate the bug and to review the fix. Well, everybody :-D Sometimes, for more complex fixes than usual, I'm trying to write a more specific message than my regular message ;-)
Closing automatically an issue is not incompatible with saying thanks to people who helped to get it fixed. You can still comment on a closed issue, and people who are subscribed to the bug will be notified by email.
Victor
Night gathers, and now my watch begins. It shall not end until my death.
On Mon, Oct 12, 2020 at 11:50 AM Victor Stinner <vstinner@python.org> wrote:
Closing automatically an issue is not incompatible with saying thanks to people who helped to get it fixed. You can still comment on a closed issue, and people who are subscribed to the bug will be notified by email.
That's true, but isn't the whole point of automatically closing an issue to avoid having to browse to the issue page to close it manually?
To be clear, I support such automation. What I'm trying to say is that we should use such automation not only to avoid busy-work but also to help us do things like thanking contributors.
- Tal
participants (5)
-
Berker Peksağ -
Gregory P. Smith -
Guido van Rossum -
Tal Einat -
Victor Stinner