[Python-Dev] Re: Is the Python review process flawed?

[Steve Holden]

On Fri, Jul 2, 2021 at 12:47 AM  wrote:

> Okay so I just code a little bit and I used the multiprocessing module but
> my code didn't work and I found the solution on Stack Overflow and it
> turned out to be not my mistake (which has never happened before I think).
> Instead I found out it's a bug in Python and the issue on Github was linked
> so I opened it and I was surprised to see what's going on "behind the
> scenes".
>
> Yes I have basically no experience in maintaining any big project. So when
> you're saying "You don't know what it's like and therefore your complaint
> doesn't make sense" then you're not wrong and I just have to believe you.
> But I think this is a dangerous argument because it could also be used to
> shut up anything and anybody. (I'm not saying this is the case here.)
> Therefore, this argument should rarely be used in my opinion. From an
> outsider's perspective it just looks really weird that a bugfix from 2017
> hasn't become a priority to get merged, like the process is flawed. That's
> all. I didn't mean to attack any one of you. I want to make that clear
> because it feels like some of you got kinda defensive about it.
>
> I don't think anyone felt attacked. The hard-working devs are merely
trying to explain the facts of life, and if exasperation occasionally
creeps in that's probably because this is far from the first time this
issue has been raised here. (You'll note I refer to the core devs in the
third person, since I am not one of them and neither do I speak for them, I
am merely recording my observations).

"There's been quite a bit of discussion on both of them" - None of the
> discussions left any questions unanswered. Except for the question of when
> the pull request will get merged.
>
> "Merging something is also a responsibility to whoever does it" - And it's
> also a responsibility to fix bugs, no? I don't get why you're so afraid of
> (maybe!) introducing a new bug when there already (certainly!) is a bug.
>
> Whose "responsibility" do you think it should be to fix bugs?  Who do you
think should set priorities to determine which work is done first. Few core
developers are paid to work on Python, and even those that are (until the
PSF's developer is appointed) might expect to have their overall priorities
set by their employer. As a consumer of their work who's made little
contribution to the language I don't personally feel that I have much right
to dictate how devs spend their time. I'm just glad so many of them do.

The fact is that for any community-run open source project the only
reliable way to ensure PRs get merged is to acquire commit rights and do it
yourself. It's by no means ideal, but that's the current reality for Python.

"Oops. I'm really sorry for giving false hopes, then, because I don't think
> I'm motivated to review this PR. I'm not really maintaining multiprocessing
> these days, anymore" - No worries dude. This not about one person or one
> bug. I'm sorry that the issue that I stumbled upon turned out to be one
> where you said you'd put it on your list.
>
> "What if that one line change is even more wrong than before?" - Yes of
> course there's a risk. Just like there was a risk when you merged the
> original code which contained the bug, right?! At some point you have to
> say yes that looks okay let's merge it, even though there is a slight
> chance it could contain a mistake. And it is not obvious to me (and many
> other people who commented in those github threads) what else would
> possibly be needed. After all, there are currently actual people who are
> affected by the bug - and you're only talking about hypothetical people
> being affected by a possibly wrong bugfix.
>
> Let's assume that it takes an hour to properly review and merge a PR. If
someone only has five hours a week to work on Python they are hardly going
to consider spending 20% of their available time tht week on
sometthing unrelted to the work they've been doint of rk

> "When I got the shutil.which feature merged, the PR had been open for I
> believe 11 years" - Totally different topic. I explicitly said in my
> initial message, that I'm talking about a bugfix, not a new feature.
>
> "If you would like more value out of it or to speed up the process, you
> can provide your own reviews." - Seriously? I can't help but feel like that
> comment sounds kinda arrogant. I hope I'm misunderstanding you. Look at
> that link and Stack Overflow post again how many people commented and voted
> that the patch fixed their issues. How many more people do you want?
>
> It isn't a matter of summoning the desire, it's a matter of allocating
time.


> "*maintainer attention* is actually the scarcest resource in many open
> source projects, and Python is no exception." - Then get more people to do
> this? Don't tell me Python isn't big enough to find some companies or funds
> to sponsor a few people to work the dreaded reviewer job a few hours a
> week? Or let more amateur coders 

[Python-Dev] Re: Is the Python review process flawed?

[Jim J. Jewett]

esmeraldagarcia＠byom.de wrote:

>> "If you would like more value out of it or to speed
>> up the process, you can provide your own reviews." - 

> Seriously? I can't help but feel like that comment
> sounds kinda arrogant.

I've done it and it sometimes helps.  That said, there is still a problem -- it 
isn't always easy to tell at a glance which issues are reviewed and apparently 
OK.  

There is a Stage field that can be changed from Patch Review to Commit Review, 
and at least some core committers seem to search on that.  

If you have specific suggestions on better ways to signal "This is important, 
as confirmed by [StackOverflow / twitter thread / downstream bug report ...]" 
or "This patch has already been reviewed and someone besides the author thinks 
it is ready", that could be very helpful.  And now would be a great time to 
suggest such improvements, since the bug tracker may be migrated soon.
 
>> "Most stdlib modules have no maintainer and past
>> maintainers are gone for a long time." 

> - I'm flabbergasted. I don't know what to say.
> Can't you not see how bad that is?!

I can, but it is also true of almost every long-term project I have worked on 
for pay.

-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AEVOUI6SAMFRK2VA5C6E3XMINRYWWRE3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Guido van Rossum]

Can we call this discussion closed? There’s not much more to be said. I’m
not picking on you, Chris, I just think that not much will be gained by
continuing the thread.

I appreciate Esmeralda’s messages and all the responses. Now let’s go fix
some bugs! :-)

(Obligatory XKCD comic:
https://xkcd.com/386/ )

—Guido

On Thu, Jul 1, 2021 at 17:55 Chris Angelico  wrote:

> On Fri, Jul 2, 2021 at 10:06 AM Eric V. Smith  wrote:
> >
> > On 7/1/2021 7:39 PM, esmeraldagar...@byom.de wrote:
> > > "Merging something is also a responsibility to whoever does it" - And
> it's also a responsibility to fix bugs, no? I don't get why you're so
> afraid of (maybe!) introducing a new bug when there already (certainly!) is
> a bug.
> >
> > Because the new bug you introduce might be much, much worse than the bug
> > you're fixing.
> >
>
> It's worth noting that, in the (rare) cases where there clearly is no
> downside to fixing a bug... it just gets fixed. You won't see those
> kinds of issues in Stack Overflow answers, because they're not there
> any more. Calling the review process flawed on the basis of the issues
> still open after X years is as incomplete a picture as saying that all
> music from the 18th century is awesome on the basis of the music
> that's still being played today. *By definition*, you're only seeing
> the hairy issues, the ones where it's far from clear what the correct
> action is (merge, modify, or do nothing).
>
> If you want a rough idea of the things that get fixed quietly, browse
> the What's New for a point release, for example:
>
> https://www.python.org/downloads/release/python-394/
>
> ChrisA
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TC6MFY6HEQEV4XPLSRMYDMFAOU32WJ6V/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ADCWVLNPVJF2EAZ5B22YT4CLBRL7NQPN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Brett Cannon]

On Thu, Jul 1, 2021 at 4:54 PM  wrote:

> Okay so I just code a little bit and I used the multiprocessing module but
> my code didn't work and I found the solution on Stack Overflow and it
> turned out to be not my mistake (which has never happened before I think).
> Instead I found out it's a bug in Python and the issue on Github was linked
> so I opened it and I was surprised to see what's going on "behind the
> scenes".
>
> Yes I have basically no experience in maintaining any big project. So when
> you're saying "You don't know what it's like and therefore your complaint
> doesn't make sense" then you're not wrong and I just have to believe you.
> But I think this is a dangerous argument because it could also be used to
> shut up anything and anybody. (I'm not saying this is the case here.)
> Therefore, this argument should rarely be used in my opinion. From an
> outsider's perspective it just looks really weird that a bugfix from 2017
> hasn't become a priority to get merged, like the process is flawed. That's
> all. I didn't mean to attack any one of you. I want to make that clear
> because it feels like some of you got kinda defensive about it.
>

We do get defensive because people on a regular basis come to us asking,
"why haven't you fixed this?" and we have to explain why, and some people
accept the answer and others continue to push us which in all honesty
becomes exhausting. Add on that not everyone asking in an understanding,
kind way and it makes one not want to even reply most of the time.


>
> "There's been quite a bit of discussion on both of them" - None of the
> discussions left any questions unanswered. Except for the question of when
> the pull request will get merged.
>
> "Merging something is also a responsibility to whoever does it" - And it's
> also a responsibility to fix bugs, no? I don't get why you're so afraid of
> (maybe!) introducing a new bug when there already (certainly!) is a bug.
>
> "Oops. I'm really sorry for giving false hopes, then, because I don't
> think I'm motivated to review this PR. I'm not really maintaining
> multiprocessing these days, anymore" - No worries dude. This not about one
> person or one bug. I'm sorry that the issue that I stumbled upon turned out
> to be one where you said you'd put it on your list.
>
> "What if that one line change is even more wrong than before?" - Yes of
> course there's a risk. Just like there was a risk when you merged the
> original code which contained the bug, right?! At some point you have to
> say yes that looks okay let's merge it, even though there is a slight
> chance it could contain a mistake. And it is not obvious to me (and many
> other people who commented in those github threads) what else would
> possibly be needed. After all, there are currently actual people who are
> affected by the bug - and you're only talking about hypothetical people
> being affected by a possibly wrong bugfix.
>

As Eric points out in his own follow-up, sometimes the fix is worse than
the bug it's fixing. Add to that the feeling when people descend upon you
for breaking their code that was working due to a "bugix" which from their
view wasn't, and it makes you very cautious about accepting any PR w/o
having a solid understanding of the ramifications. I have people come up to
me at PyCon US about code I have changed over a decade ago to complain
about it. It's exhausting sometimes.


>
> "When I got the shutil.which feature merged, the PR had been open for I
> believe 11 years" - Totally different topic. I explicitly said in my
> initial message, that I'm talking about a bugfix, not a new feature.
>
> "If you would like more value out of it or to speed up the process, you
> can provide your own reviews." - Seriously? I can't help but feel like that
> comment sounds kinda arrogant. I hope I'm misunderstanding you. Look at
> that link and Stack Overflow post again how many people commented and voted
> that the patch fixed their issues. How many more people do you want?
>

A SO comment is not a code review. What was being requested is someone not
only validating the fix but making sure the code is solid, meets coding
guidelines, has appropriate tests, etc. There is much more to maintaining
the code than just whether it functions appropriately.


>
> "*maintainer attention* is actually the scarcest resource in many open
> source projects, and Python is no exception." - Then get more people to do
> this? Don't tell me Python isn't big enough to find some companies or funds
> to sponsor a few people to work the dreaded reviewer job a few hours a week?


Welcome to open source and why it is perpetually underfunded. The PSF just
got funding for the first time in Python's 30 year history this year to
hire someone to work on Python full-time. I get 20% for open source from my
employer and I am very lucky to get that plus whatever time I spend away
from family and friends in my spare time (like now while I reply to this
during a holiday).

Or 

[Python-Dev] Re: Is the Python review process flawed?

[Chris Angelico]

On Fri, Jul 2, 2021 at 10:06 AM Eric V. Smith  wrote:
>
> On 7/1/2021 7:39 PM, esmeraldagar...@byom.de wrote:
> > "Merging something is also a responsibility to whoever does it" - And it's 
> > also a responsibility to fix bugs, no? I don't get why you're so afraid of 
> > (maybe!) introducing a new bug when there already (certainly!) is a bug.
>
> Because the new bug you introduce might be much, much worse than the bug
> you're fixing.
>

It's worth noting that, in the (rare) cases where there clearly is no
downside to fixing a bug... it just gets fixed. You won't see those
kinds of issues in Stack Overflow answers, because they're not there
any more. Calling the review process flawed on the basis of the issues
still open after X years is as incomplete a picture as saying that all
music from the 18th century is awesome on the basis of the music
that's still being played today. *By definition*, you're only seeing
the hairy issues, the ones where it's far from clear what the correct
action is (merge, modify, or do nothing).

If you want a rough idea of the things that get fixed quietly, browse
the What's New for a point release, for example:

https://www.python.org/downloads/release/python-394/

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TC6MFY6HEQEV4XPLSRMYDMFAOU32WJ6V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Eric V. Smith]

On 7/1/2021 7:39 PM, esmeraldagar...@byom.de wrote:

"Merging something is also a responsibility to whoever does it" - And it's also 
a responsibility to fix bugs, no? I don't get why you're so afraid of (maybe!) 
introducing a new bug when there already (certainly!) is a bug.


Because the new bug you introduce might be much, much worse than the bug 
you're fixing.


Eric

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6YVBECAGLFKPDYM5LSX37HZUTMOXXCBJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Steve Dower]

On 7/1/2021 7:04 PM, Christopher Barker wrote:
PS: All that being said, we, as a community, could do better. For 
instance, someone like me could do high-level triage on bug reports -- I 
need to set aside some time to do that.


In addition/instead of triage, one thing we (as core maintainers) really 
need, which the more involved members of the wider community can 
provide, is *context*.


I presume that if you're on python-dev, you probably have (or have 
access to) a significant Python codebase. Many core developers do as 
well, but we know we don't have great view across all the different ways 
that Python gets used. Some of the "worst" regressions are due to 
scenarios that we simply didn't know existed until they were broken.


We don't need (or wouldn't benefit from) just seeing all of the code, 
because it's the understanding that's important. How would changes 
impact *your* projects, *your* users. Anywhere you can chip in with "we 
do XYZ and this change would [not] impact us this way" or "we'd have to 
mitigate it by doing ..." is very useful.


It's not just a vote, it's the added context that's helpful. Ultimately, 
"votes" don't count for much in merge/reject decisions, because we're 
trying to take into account all users, not just those who show up to 
click a button. Rational arguments based in real and personal impact 
statements are far more valuable, especially if you have context that we 
don't.


So feel free to drop into bugs or PRs when you have relevant context for 
the impact of a change. Try and be as detailed about the impact on you 
as you're allowed (or can be without distracting from the issue). Don't 
be offended if we still think that the impact is "worth it" or that your 
situation isn't actually as impacted as you think (that probably 
indicates that we need to do a better NEWS/Whats New entry for the change).


And yes, these can be *significant contributions* to the project, so if 
you find yourself in a position where you have to justify it to someone 
outside of the project (e.g. using work time for open source), hopefully 
any core developer you've interacted with a bit will gladly write a 
short endorsement for that.


Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BB3YX3J5NZHBUKCV67O34TPVQLD2CLWA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[esmeraldagarcia]

Okay so I just code a little bit and I used the multiprocessing module but my 
code didn't work and I found the solution on Stack Overflow and it turned out 
to be not my mistake (which has never happened before I think). Instead I found 
out it's a bug in Python and the issue on Github was linked so I opened it and 
I was surprised to see what's going on "behind the scenes".

Yes I have basically no experience in maintaining any big project. So when 
you're saying "You don't know what it's like and therefore your complaint 
doesn't make sense" then you're not wrong and I just have to believe you. But I 
think this is a dangerous argument because it could also be used to shut up 
anything and anybody. (I'm not saying this is the case here.) Therefore, this 
argument should rarely be used in my opinion. From an outsider's perspective it 
just looks really weird that a bugfix from 2017 hasn't become a priority to get 
merged, like the process is flawed. That's all. I didn't mean to attack any one 
of you. I want to make that clear because it feels like some of you got kinda 
defensive about it.

"There's been quite a bit of discussion on both of them" - None of the 
discussions left any questions unanswered. Except for the question of when the 
pull request will get merged.

"Merging something is also a responsibility to whoever does it" - And it's also 
a responsibility to fix bugs, no? I don't get why you're so afraid of (maybe!) 
introducing a new bug when there already (certainly!) is a bug.

"Oops. I'm really sorry for giving false hopes, then, because I don't think I'm 
motivated to review this PR. I'm not really maintaining multiprocessing these 
days, anymore" - No worries dude. This not about one person or one bug. I'm 
sorry that the issue that I stumbled upon turned out to be one where you said 
you'd put it on your list.

"What if that one line change is even more wrong than before?" - Yes of course 
there's a risk. Just like there was a risk when you merged the original code 
which contained the bug, right?! At some point you have to say yes that looks 
okay let's merge it, even though there is a slight chance it could contain a 
mistake. And it is not obvious to me (and many other people who commented in 
those github threads) what else would possibly be needed. After all, there are 
currently actual people who are affected by the bug - and you're only talking 
about hypothetical people being affected by a possibly wrong bugfix.

"When I got the shutil.which feature merged, the PR had been open for I believe 
11 years" - Totally different topic. I explicitly said in my initial message, 
that I'm talking about a bugfix, not a new feature.

"If you would like more value out of it or to speed up the process, you can 
provide your own reviews." - Seriously? I can't help but feel like that comment 
sounds kinda arrogant. I hope I'm misunderstanding you. Look at that link and 
Stack Overflow post again how many people commented and voted that the patch 
fixed their issues. How many more people do you want?

"*maintainer attention* is actually the scarcest resource in many open source 
projects, and Python is no exception." - Then get more people to do this? Don't 
tell me Python isn't big enough to find some companies or funds to sponsor a 
few people to work the dreaded reviewer job a few hours a week? Or let more 
amateur coders review and have a core reviewer review their reviews? I totally 
get the point that reviewers are a scarce resource. But I do not get the point 
why you're not changing that.

"almost by definition, ANY regression is worse than any bug that still exists 
today" - Yeah I get this point and I think I agree. But it's more about risk 
evaluation. Because if there is absolutely no willingness to risk mistakenly 
introducing a regression then you're effectively at a standstill. You can never 
merge anything again because it might affect the code base in a way you hadn't 
foreseen. So you need to take some risks.

"Most stdlib modules have no maintainer and past maintainers are gone for a 
long time." - I'm flabbergasted. I don't know what to say. Can't you not see 
how bad that is?!

"As specifically to the flaws in our workflow and the backlog, this is exactly 
what the  was designed to address" - To end on a positive note: The 
Developer-in-Residence program sounds like a really good idea. And I love 
Python and appreciate all the work that went into it and I really hope all of 
you believe me when I say this despite me internet rando pooping on your review 
process. <3
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TXCVYKKNKAAF5M7RSCWRWPQLYDVXLCW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Christopher Barker]

Just to add a comment from someone who's been around Python a long time --
a (very) occasional contributor, never a maintainer.

I have every sympathy for the core maintainers -- Python is a very large
and complex project that is relied on by an enormous number of people.

The size and complexity (and age of the code base) make it a real challenge
to maintain, and the size of the user community makes the consequences of a
regression massive.

> Tests make us a little more certain, but it is still a guess.

Exactly -- I am a big fan of unit testing and TDD. But whenever I teach
about unit testing, I always say:

"comprehensive tests are a fantasy"

Think of how hard it can be to even get 100% coverage in your tests. Then
think about how the fact that every line of code was run in no way means
every function has been run with every possible input. Then think about the
fact that cPython is a language implementation -- everything in the
interpreter is being driven at another level by arbitrarily complex Python
code.

I think it's a near miracle that anything gets updated or fixed without
major regressions!

Finally -- cPython has been around a long time, and used an enormous amount
-- any existing bugs have been avoided or worked around already by
thousands of projects -- almost by definition, ANY regression is worse than
any bug that still exists today (Security issues being an exception).

Obligatory XKCD:

https://xkcd.com/1172/

Thanks to all contributors and maintainers,

-CHB

PS: All that being said, we, as a community, could do better. For instance,
someone like me could do high-level triage on bug reports -- I need to set
aside some time to do that.


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/32BS57QPQJA7PFGY6J3NYRB44K2QJQLM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Kyle Stanley]

On Thu, Jul 1, 2021 at 10:49 AM Victor Stinner  wrote:

> What happens usually is that some modules have no maintainer. Once you
> merge a single change in a module, boom! You are now the new
> maintainer for your entire life time! More and more people will ask
> you to look at their "very important" bug blocking their production
> and their very specific use case. You will get more and more reviews
> request: "since you merged a single change 12 months ago, I'm sure
> that you will love to review my precius bugfix! Come on, it's
> trivial!". Now you realize that you don't know the design of the
> module. You don't know its history. You know nothing, and the entire
> world now have very high expectation, since you merged an obvious and
> trivial change.
>
“The ancient Oracle said that I was the wisest of all the Greeks. It is
because I alone, of all the Greeks, know that I know nothing.” ~  Socrates

The same could largely be applied to maintaining open source (especially a
codebase as large as CPython). The truth is that at a fundamental level,
we're all (any software developer) just making educated guesses as to
whether or not patches are suitable for merging, or whether or not a bug
fix will actually work. Tests make us a little more certain, but it is
still a guess. So the problem is really just the unrealistic expectation
that there exists people who are able to make a decision with absolute 100%
certainty that no regressions or future unexpected issues will occur as a
result of the change.

Also, for fun, here's a pythonized version of the quote:
“[Guido] said that I was the wisest of all the [pythonistas]. It is because
I alone, of all the [pythonistas], know that I know nothing.”
:)

With loving-kindness,
-- 
--Kyle R. Stanley, Python Core Developer (what is a core dev?
)
*Pronouns: they/them **(why is my pronoun here?*

)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SGDPAXGBI2627HFBK7NV5GQWDXDSRR4W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Victor Stinner]

Thanks Brian for your nice summary! Let me complete it.

Warning: I didn't look at https://github.com/python/cpython/pull/4819
at all. My email is a really general remark on the Python workflow.
You in this email is not the OP, but "any contributor" ;-)

What contributors don't see is that regressions are very common in
Python: bugs introduced by recent changes (feature or bugfix).
Usually, the author of the change is gone when the regression pops up,
and the core developers who merged the PR "must" handle the
regression.

And it's not about a single regression and you're done ever, you can
get more. In the worst case, the fix for a regression introduced a
second regression. And then you have to handle new backward
compatibility issue when fixing a stable Python version :-(

What happens usually is that some modules have no maintainer. Once you
merge a single change in a module, boom! You are now the new
maintainer for your entire life time! More and more people will ask
you to look at their "very important" bug blocking their production
and their very specific use case. You will get more and more reviews
request: "since you merged a single change 12 months ago, I'm sure
that you will love to review my precius bugfix! Come on, it's
trivial!". Now you realize that you don't know the design of the
module. You don't know its history. You know nothing, and the entire
world now have very high expectation, since you merged an obvious and
trivial change.

It happens to me all the time. Most stdlib modules have no maintainer
and past maintainers are gone for a long time.

Merging a PR is very "expensive" for a core developer. There are very
good reasons to not merge a PR. The status quo is much more
comfortable for the core dev who decided to *not* be the one who
merged your PR.

I prefer to pretend that I know nothing about Python and only focus on
the code area that I know the best, to reduce the risk of regression
when merging a change. If you don't know well a module, the risk of
missing a bug (breaking a specific code path) is way higher.

The other problem is that it's very rare that a PR is reviewed by more
than a single core developer. The core developer will be the only
responsible person to handle the future incoming mess introduced by
the "obvious and short bugfix".

I exaggerate the severity of regressions to explain my point, but
trust me, they are more likely than what you are thinking. Also, more
contributors are around for 1 to 6 months, whereas core developers are
usually around for 1 to 5 years. It's a different time scale in terms
of responsibilities.

Victor

On Tue, Jun 29, 2021 at 7:21 PM Brian Curtin  wrote:
>
> On Tue, Jun 29, 2021 at 10:38 AM  wrote:
>>
>> I just stumbled upon the following issue and subsequent pull request. It is 
>> a very small bugfix. There is currently a bug in Python and this pull 
>> request fixes it. It's not a new feature or an enhancement, it is a bugfix! 
>> Yet, it doesn't get reviewed, nor merged. And this has been going on since 
>> March 2017. Why not just merge this? It's not like it's huge or obstructing 
>> or obfuscating the current code base? There's always time to write an 
>> improvement or a complete rewrite of this module feature later for an 
>> upcoming minor release. But if there is currently a bug in Python and the 
>> bugfix is available - why doesn't it get merged?
>>
>> https://github.com/python/cpython/pull/4819
>
>
> For starters, the PR is closed in favor of another issue that has reviews and 
> a discussion, but even the smallest change like that requires a lot out of a 
> reviewer. Looking at that change, I don't personally know that it's correct, 
> so I'd have to take the time to figure out that it's correct. It includes no 
> tests, so I certainly don't trust that it's correct, so it looks incomplete 
> to me.
>
> Time is irrelevant here—there's no need to rush things because a change 
> appears small. What if that one line change is even more wrong than before? I 
> have merge access and if I just said "ah it's a small PR and it's been open 
> for a while, I'll just merge it for them," any change to Python has the 
> possibility to affect a huge amount of people.
>
> When I got the shutil.which feature merged, the PR had been open for I 
> believe 11 years and it was mostly complete in the initial patch outside of a 
> few small issues, and the change itself wasn't a lot of code. To just have 
> merged it because it was open for 11 years would have been the wrong thing to 
> do. It needed to cover some things it didn't initially cover, it needed tests 
> and documentation, and it wasn't merged until it was completed and properly 
> reviewed.
>
>> If this doesn't get fixed, doesn't that mean the Python review process is 
>> flawed? Sure, Python is an open source project and many people just work in 
>> their free time. But this doesn't really apply here, does it? The bugfix is 
>> available. Only a review is required. All this is 

[Python-Dev] Re: Is the Python review process flawed?

[Antoine Pitrou]

On Tue, 29 Jun 2021 13:56:18 -0300
Joannah Nanjekye  wrote:
>  > why doesn't it get merged?  
> 
> The last significant discussion from a core dev on the most relevant PR
> here: https://github.com/python/cpython/pull/4819
> shows that Antoine was familiarizing himself with the feature and had added
> it to their to do list.

Oops. I'm really sorry for giving false hopes, then, because I don't
think I'm motivated to review this PR. I'm not really maintaining
multiprocessing these days, anymore.

Hopefully some other core developer would like to take a look, but
we're talking about a slightly niche feature of multiprocessing...

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3R7HNT76BD7LSPLD3ONXOYYAEHCETSOQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Guido van Rossum]

On Tue, Jun 29, 2021 at 9:34 AM  wrote:

> If this doesn't get fixed, doesn't that mean the Python review process is
> flawed? Sure, Python is an open source project and many people just work in
> their free time. But this doesn't really apply here, does it? The bugfix is
> available. Only a review is required. All this is happening while new
> features get added to Python with every new minor version. While the bug is
> allowed to live there. Please help me understand how this can happen.
>

I think there's a misunderstanding here -- you seem to imply that producing
a bugfix is work that takes somebody's time, while reviewing a bugfix is
not work and doesn't cost anything. But realistically, for most issues,
things are the other way around -- writing the code is easy (at least to a
core dev :-) but reviewing code is a gut-wrenching process that takes up
emotional energy and a lot of time. Given the discussion in the issue
corresponding to the PR it is clear that that is what is going on here.

As Nadia Eghbal writes in her book _Working In Public_, *maintainer
attention* is actually the scarcest resource in many open source projects,
and Python is no exception. It is also the least satisfying kind of work,
which is why volunteers prefer to work on new features.


> I love Python. No hard feelings. But this is really bugging me and I can't
> help but feel disappointed.
>

Thank you for that! Hopefully all the responses you are getting help you
see why this is not so simple.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5ECXASFZT7CKHLE443ZQXZAIRGIJ7H4F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Brian Curtin]

On Tue, Jun 29, 2021 at 10:38 AM  wrote:

> I just stumbled upon the following issue and subsequent pull request. It
> is a very small bugfix. There is currently a bug in Python and this pull
> request fixes it. It's not a new feature or an enhancement, it is a bugfix!
> Yet, it doesn't get reviewed, nor merged. And this has been going on since
> March 2017. Why not just merge this? It's not like it's huge or obstructing
> or obfuscating the current code base? There's always time to write an
> improvement or a complete rewrite of this module feature later for an
> upcoming minor release. But if there is currently a bug in Python and the
> bugfix is available - why doesn't it get merged?
>
> https://github.com/python/cpython/pull/4819


For starters, the PR is closed in favor of another issue that has reviews
and a discussion, but even the smallest change like that requires a lot out
of a reviewer. Looking at that change, I don't personally know that it's
correct, so I'd have to take the time to figure out that it's correct. It
includes no tests, so I certainly don't trust that it's correct, so it
looks incomplete to me.

Time is irrelevant here—there's no need to rush things because a change
appears small. What if that one line change is even more wrong than before?
I have merge access and if I just said "ah it's a small PR and it's been
open for a while, I'll just merge it for them," any change to Python has
the possibility to affect a huge amount of people.

When I got the shutil.which feature merged, the PR had been open for I
believe 11 years and it was mostly complete in the initial patch outside of
a few small issues, and the change itself wasn't a lot of code. To just
have merged it because it was open for 11 years would have been the wrong
thing to do. It needed to cover some things it didn't initially cover, it
needed tests and documentation, and it wasn't merged until it was completed
and properly reviewed.

If this doesn't get fixed, doesn't that mean the Python review process is
> flawed? Sure, Python is an open source project and many people just work in
> their free time. But this doesn't really apply here, does it? The bugfix is
> available. Only a review is required. All this is happening while new
> features get added to Python with every new minor version. While the bug is
> allowed to live there. Please help me understand how this can happen.
>

"Only a review is required" is vastly understating the value of code
reviews. Almost anybody can write a one line fix, but is it the right fix?
Does it cover all of the cases it needs to? Is adding "manager_owned=False"
correct or should something else actually be done? Who knows and is
available to understand the impacts of this change?

So does this mean the review process is flawed? I would say no, the _review
process_ is maybe working as expected—the linked PR was incomplete and
wasn't merged, another PR has come up, and there's discussion on it
including a comment about tests and one about familiarizing with the code.
The process of finding humans who are willing and able to do this
work—currently for free—is possibly broken, possibly working as expected,
and overall is a significantly harder problem to fix than most anything
involved with open source software.

I love Python. No hard feelings. But this is really bugging me and I can't
> help but feel disappointed.
>

The good thing is that you paid nothing for this, so being disappointed is
something you can fix. If you would like more value out of it or to speed
up the process, you can provide your own reviews. Reviewing code is
immensely valuable and helps so many people—the core developers, the users,
and yourself. Alternatively, paying people to do the reviews is also
possible.

___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TTJAVTPF6RYO63GTBSTXFJG3IVCYPHXT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5PYTF4BEKS3H2AZX6ZQXKIQM5SYTOH7H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Barry Warsaw]

As specifically to the flaws in our workflow and the backlog, this is exactly 
what the Developer-in-Residence program was designed to address:

https://pyfound.blogspot.com/2021/04/the-psf-is-hiring-developer-in.html

Stay tuned!
-Barry

> On Jun 29, 2021, at 09:56, Joannah Nanjekye  wrote:
> 
> > why doesn't it get merged?
> 
> The last significant discussion from a core dev on the most relevant PR here: 
> https://github.com/python/cpython/pull/4819
> shows that Antoine was familiarizing himself with the feature and had added 
> it to their to do list.
> 
> Merging something is also a responsibility to whoever does it, so I suggest 
> we approach this with grace given at least someone
> promised to look into it.
> 
> BTW, am not writing off your concerns.
> 
> On Tue, Jun 29, 2021 at 1:36 PM  wrote:
> I just stumbled upon the following issue and subsequent pull request. It is a 
> very small bugfix. There is currently a bug in Python and this pull request 
> fixes it. It's not a new feature or an enhancement, it is a bugfix! Yet, it 
> doesn't get reviewed, nor merged. And this has been going on since March 
> 2017. Why not just merge this? It's not like it's huge or obstructing or 
> obfuscating the current code base? There's always time to write an 
> improvement or a complete rewrite of this module feature later for an 
> upcoming minor release. But if there is currently a bug in Python and the 
> bugfix is available - why doesn't it get merged?
> 
> https://github.com/python/cpython/pull/4819
> 
> If this doesn't get fixed, doesn't that mean the Python review process is 
> flawed? Sure, Python is an open source project and many people just work in 
> their free time. But this doesn't really apply here, does it? The bugfix is 
> available. Only a review is required. All this is happening while new 
> features get added to Python with every new minor version. While the bug is 
> allowed to live there. Please help me understand how this can happen.
> 
> I love Python. No hard feelings. But this is really bugging me and I can't 
> help but feel disappointed.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/TTJAVTPF6RYO63GTBSTXFJG3IVCYPHXT/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> --
> Best,
> Joannah Nanjekye
> "You think you know when you learn, are more sure when you can write, even 
> more when you can teach, but certain when you can program."
> Alan J. Perlis
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/BCGNYV73S2O44OJ3OT2L3HKDK3BFLAE3/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KJW4WBL27EB7EDVYDC3HL22VGXYJZ7SF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Joannah Nanjekye]

 > why doesn't it get merged?

The last significant discussion from a core dev on the most relevant PR
here: https://github.com/python/cpython/pull/4819
shows that Antoine was familiarizing himself with the feature and had added
it to their to do list.

Merging something is also a responsibility to whoever does it, so I suggest
we approach this with grace given at least someone
promised to look into it.

BTW, am not writing off your concerns.

On Tue, Jun 29, 2021 at 1:36 PM  wrote:

> I just stumbled upon the following issue and subsequent pull request. It
> is a very small bugfix. There is currently a bug in Python and this pull
> request fixes it. It's not a new feature or an enhancement, it is a bugfix!
> Yet, it doesn't get reviewed, nor merged. And this has been going on since
> March 2017. Why not just merge this? It's not like it's huge or obstructing
> or obfuscating the current code base? There's always time to write an
> improvement or a complete rewrite of this module feature later for an
> upcoming minor release. But if there is currently a bug in Python and the
> bugfix is available - why doesn't it get merged?
>
> https://github.com/python/cpython/pull/4819
>
> If this doesn't get fixed, doesn't that mean the Python review process is
> flawed? Sure, Python is an open source project and many people just work in
> their free time. But this doesn't really apply here, does it? The bugfix is
> available. Only a review is required. All this is happening while new
> features get added to Python with every new minor version. While the bug is
> allowed to live there. Please help me understand how this can happen.
>
> I love Python. No hard feelings. But this is really bugging me and I can't
> help but feel disappointed.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TTJAVTPF6RYO63GTBSTXFJG3IVCYPHXT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Best,
Joannah Nanjekye

*"You think you know when you learn, are more sure when you can write, even
more when you can teach, but certain when you can program." Alan J. Perlis*
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BCGNYV73S2O44OJ3OT2L3HKDK3BFLAE3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Chris Angelico]

On Wed, Jun 30, 2021 at 2:36 AM  wrote:
>
> I just stumbled upon the following issue and subsequent pull request. It is a 
> very small bugfix. There is currently a bug in Python and this pull request 
> fixes it. It's not a new feature or an enhancement, it is a bugfix! Yet, it 
> doesn't get reviewed, nor merged. And this has been going on since March 
> 2017. Why not just merge this? It's not like it's huge or obstructing or 
> obfuscating the current code base? There's always time to write an 
> improvement or a complete rewrite of this module feature later for an 
> upcoming minor release. But if there is currently a bug in Python and the 
> bugfix is available - why doesn't it get merged?
>
> https://github.com/python/cpython/pull/4819
>
> If this doesn't get fixed, doesn't that mean the Python review process is 
> flawed? Sure, Python is an open source project and many people just work in 
> their free time. But this doesn't really apply here, does it? The bugfix is 
> available. Only a review is required. All this is happening while new 
> features get added to Python with every new minor version. While the bug is 
> allowed to live there. Please help me understand how this can happen.
>
> I love Python. No hard feelings. But this is really bugging me and I can't 
> help but feel disappointed.
>

It looks like that was closed in favour of a different PR:

https://github.com/python/cpython/pull/16341

There's been quite a bit of discussion on both of them. Are you sure
you linked to the correct pull request?

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HW7IWAAYKSTOMXCXAVAZM3L7RGFSTBTO/
Code of Conduct: http://python.org/psf/codeofconduct/