On Thu, Jul 1, 2021 at 4:54 PM <esmeraldagar...@byom.de> 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 put another way: does your employer pay for you or anyone else to
contribute to Python? Or are they a sponsor of the PSF?


> Or let more amateur coders review and have a core reviewer review their
> reviews?


Anyone can do code reviews; it's one of the reasons we are on GitHub and
someone asked you to please provide a code review.


> I totally get the point that reviewers are a scarce resource. But I do not
> get the point why you're not changing that.
>

We can't force people to give us funding, or force companies to hire folks
to work on Python, or make people give code reviews. I have personally put
it in a vast amount of my personal time trying to lower the barrier of
entry for people on this project as well as make reviews easier. But you
simply can't will people to help out.


>
> "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.
>

Yes, but you have to balance that risk out, and that risk calculation may
or may not go the way you want (as you're discovering).


>
> "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?!
>

Sure, which is why we cleaned up the stdlib when we transitioned to Python
3.0 and we have https://www.python.org/dev/peps/pep-0594/ under
consideration. But do understand that if we dropped every module that
lacked a direct maintainer there wouldn't be much of a stdlib anymore
(which perhaps you're fine with; everyone has an opinion on this topic and
I will be starting a chat on this in the future 😅).


>
> "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
>

I think a key thing to keep in mind is this has been our overall dev
process of literally decades and it has produced this software that you
love. So do understand that while you may be shocked by "how the sausage is
made", it has gotten you something you have admitted you love overall.

If you want to read more about the difficulties in balancing all of this,
I've written and spoken about it extensively, e.g.
https://snarky.ca/setting-expectations-for-open-source-participation/ and
https://snarky.ca/the-social-contract-of-open-source/.
_______________________________________________
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/EBCMOXBIYMJ2OKBPD5BHTJ62MHAWDNBB/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to