You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I opened the PR, Bedevere added "awaiting core review" (correct, I'm a core dev)
Jelle approved the PR; Bedevere removed "awaiting core review" and "awaiting merge" (correct)
I then converted the PR to draft, as I had cold feet. Bedevere removed "awaiting merge" as a result (not sure if that's correct or not? we could debate what the desirable behaviour might be there)
I then moved the PR out of draft again; Bedevere added "awaiting core review" (definitely incorrect; the PR had already been approved by a core dev)
In my mind, moving a PR to draft and then back to published is equivalent to submitting a new PR (under the unfounded assumption that you move to draft only if you want to significantly rework the PR).
I can see how other interpretations also make sense, and I don't have a strong opinion myself (especially not being a core dev :) ) and happy to look into making changes in the draft workflow - but I'd like to have someone authoritative (that someone can be you ofcourse) providing guidance about what should be the desired workflow first!
Reacted by Alex Waygood, Kirill Podoprigora and Jelle Zijlstra
under the unfounded assumption that you move to draft only if you want to significantly rework the PR
For me, that's an incorrect assumption ;)
It's not unusual for me to do testing locally, think I've got a strong PR, file it on GitHub... then get cold feet, so I'll put it back into draft while I do some more testing locally, just in case somebody else merges it while I'm doing more testing. But then my local testing proves my fears were incorrect, so I move it out of draft again without having changed much at all!
In general, I agree with Itamar. But if the commit hasn't changed since it was approved, and if it's easy to check that, I think would be nice to go straight back to "awaiting merge"
I found the sequence in python/cpython#104559 surprising, but it sounds like I might be in the minority (and it's not a huge issue, anyway), so better to do nothing here than add loads more complexity, I think :)
Let's not add more labels. In my mind if a PR already has awaiting merge label, we should not move it back to draft. You could add the "do not merge" label if you still need to work on it more. So I think the behavior that's currently implemented is correct.
Reacted by Alex Waygood, Itamar Oren and Oleg Iarygin
Activity
itamaro commentedon May 16, 2023
In my mind, moving a PR to draft and then back to published is equivalent to submitting a new PR (under the unfounded assumption that you move to draft only if you want to significantly rework the PR).
I can see how other interpretations also make sense, and I don't have a strong opinion myself (especially not being a core dev :) ) and happy to look into making changes in the draft workflow - but I'd like to have someone authoritative (that someone can be you ofcourse) providing guidance about what should be the desired workflow first!
AlexWaygood commentedon May 16, 2023
For me, that's an incorrect assumption ;)
It's not unusual for me to do testing locally, think I've got a strong PR, file it on GitHub... then get cold feet, so I'll put it back into draft while I do some more testing locally, just in case somebody else merges it while I'm doing more testing. But then my local testing proves my fears were incorrect, so I move it out of draft again without having changed much at all!
hauntsaninja commentedon May 16, 2023
In general, I agree with Itamar. But if the commit hasn't changed since it was approved, and if it's easy to check that, I think would be nice to go straight back to "awaiting merge"
itamaro commentedon May 16, 2023
I'm sure it could be done with a bunch of additional labels. I don't know if this would be considered easy (or desirable) :)
AlexWaygood commentedon May 16, 2023
More labels sounds like a bad idea!
I found the sequence in python/cpython#104559 surprising, but it sounds like I might be in the minority (and it's not a huge issue, anyway), so better to do nothing here than add loads more complexity, I think :)
Mariatta commentedon May 16, 2023
Let's not add more labels. In my mind if a PR already has awaiting merge label, we should not move it back to draft. You could add the "do not merge" label if you still need to work on it more. So I think the behavior that's currently implemented is correct.