Thanks Jeffrey Kintscher for asking this question.
It is one of those "less obvious way to triage CPython issues" kind of
thing.
I think it would be great if this workflow can be documented and clarified
in the devguide.
I've opened https://github.com/python/devguide/issues/494
ᐧ
This was more of a core-mentorship question (tracker management) than a
pydev question (Python development). But since we are here...
On 6/10/2019 11:41 PM, Mariatta wrote:
Hmm, I personally would still consider the additional issues as
duplicates. So I would make note in each of the
On Jun 10, 2019, at 23:41, Mariatta wrote:
> On Mon, Jun 10, 2019 at 8:19 PM Jeffrey Kintscher
> wrote:
>> A hypothetical example would be two different issues whose descriptions
>> appear to be for different behaviors, but are actually caused by the same
>> underlying chunk of problematic
Hmm, I personally would still consider the additional issues as duplicates.
So I would make note in each of the duplicate issue saying "this is caused
by the same problem as bpo-X", and close them, and attach the PR only to
one bpo ticket.
To decide which one I would keep open, perhaps the oldest
A hypothetical example would be two different issues whose descriptions
appear to be for different behaviors, but are actually caused by the
same underlying chunk of problematic code being called in different
ways. It could be something trivial like a corner case not being handled.
//Jeff
On
Usually we prefer 1 PR per 1 bpo ticket. The smaller the PR is, the easier
it is for us to review, and less likely to cause conflict when it comes to
auto-backporting.
When you say it resolves multiple issues, are these the same issue reported
multiple times?
ᐧ
On Mon, Jun 10, 2019 at 7:52 PM
