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/
