[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?

[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: Critique of PEP 657

[Ammar Askar]

Hi Terry,

> IDLE currently uses traceback.extract_tb and traceback.print_list

Awesome, that should work out perfectly then. Our current
proof-of-concept implementation augments the traceback.FrameSummary
class to include `end_lineno`, `colno` and `end_colno` attributes. We
will make sure to add you as a reviewer on that change so you can give
it an early shot at integrating with IDLE.

Regards,
Ammar
___
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/J622Y35DCXIBHEF72VENBJ5DX6F5ZFPJ/
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?

[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?

[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?

[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: Request for reviewers: pathlib improvements

[Barney Gale]

Hi everyone,

It’s been a fairly quiet couple of months in pathlib work from myself -
just a couple of forum posts. Kevin Follstad has been beavering away on a PR
 to address bpo-24132
, I’ve promised him a review, though
I’m already late!

I’d like to request core review of 2 PRs, having already bumped the bugs /
forum threads and waited the statuatory 5 weeks. They are:

   - PR 26153  - document and
   test pathlib.Path.absolute()
   - PR 25701  - remove
   pathlib._Accessor

The first introduces documentation and tests for a feature that has long
existed and is in widespread use.

The second removes an internal indirection layer that complicates the code
(and therefore work on other pathlib tickets).

Very appreciate to any core dev who might be able to find the time for
these.

Thank you!

Barney

On Sat, 24 Apr 2021 at 23:16, Barney Gale  wrote:

> Hi all,
>
> I hope I’m not in danger of abusing this mailing list - please let me know
> if this is too much noise.
>
> I’m very happy to share that 3 more pathlib PRs have landed - #18909
> , #25240
>  and #25277
> . Thanks for the reviews -
> I appreciate reviewer time is scarce!
>
> I may be pushing my luck here, but there are *just two* PRs outstanding
> before work on AbstractPath can begin in earnest.
>
> I would love for these to land before the 3.10 feature freeze so that we
> can spend the entire 3.11 development cycle getting the
> design/implementation of AbstractPath exactly right. The PRs are:
>
>- #25271  / bpo-42998
> - Add ‘user’ parameter to
>Path.home()
>   - A simple patch. No reviewers yet
>- #25264  / bpo-43757
> - Make Path.resolve() use
>os.path.realpath() to resolve all symlinks in a path
>   - A more complex patch with several contributions from reviewers
>   - Adds keyword-only ‘strict’ param to realpath()
>   - Now backwards compatible! No longer changes default realpath()
>   behaviour
>
> If anyone can spare the time over the next week to help get these patches
> over the line, I would really appreciate it!
>
> A quick elevator pitch for why AbstractPath is an important future feature:
>
>- pathlib is a wonderful library that beautifully shows off Python’s
>“everything is an object” approach. It’s rightly front-and-centre of many
>Python beginner tutorials. If we can extend that “everything” to include
>files in tarballs, zip files, disc images, FTP servers, S3, etc, it allows
>Python users to easily apply their pathlib knowledge to new (and common!)
>tasks.
>- In DevOps it’s common to deal with remote or embedded filesystems.
>There’s a need for pathlib-like interfaces, and that need is already met in
>popular third-party packages either by *emulating* Path APIs (often
>with subtle differences) or *hackily extending*
>Path/_Accessor/_Flavour (which is brittle and totally unsupported). Even in
>the standard library, zipfile.Path is a mostly-compatible emulation of
>pathlib.Path. Providing a supported route for extending an AbstractPath
>saves a bunch of heartache and makes the wider pathlib ecosystem more
>robust.
>
> Thanks again to everyone who has contributed their time and expertise up
> to this point.
>
> Cheers
>
> Barney
>
> On Fri, 9 Apr 2021 at 01:17, Barney Gale  wrote:
>
>> Thanks so much to everyone who discussed and reviewed the code and made
>> suggestions.
>>
>> The bulk of these patches have now landed. For those following along at
>> home, here’s a summary of the remaining PRs/bugs :
>>
>>- #18909  / bpo-39950
>>: Add Path.hardlink_to() method
>>that supersedes link_to()
>>   - Note: already under core review
>>- #25271  / bpo-42998
>>: Add ‘user’ parameter to
>>Path.home()
>>- #25240  / bpo-40107
>>: Stop using os.open() to
>>implement Path.open()
>>- #25264  / bpo-43757
>>: Make Path.resolve() use
>>os.path.realpath() to resolve all symlinks in a path
>>   - Note: changes realpath() behaviour when symlink loops are
>>   encountered (!), and adds a keyword-only 'strict' param.
>>- #25277  / bpo-39899
>>

[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?

[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 pu

[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?

[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/