5 ms·

Tangent: the post links to https://bugs.python.org/issue11416 https://bugs.python.org/issue11416 That bug makes me sad. It was opened in 2011. It's a trivial b

by js2 9y ago

Tangent: the post links to https://bugs.python.org/issue11416 https://bugs.python.org/issue11416 That bug makes me sad. It was opened in 2011. It's a trivial bug to fix. Two separate fixes were submitted, one with several iterations addressing all feedback. By my count, at least five people have dealt directly with the issue (contributing or reviewing code, providing feedback, etc). Who knows how many folks have been affected by the bug and found a work-around or gave up on it. Meanwhile, a fix ends up just withering on the vine for years. This is not a complaint specific to Python. I've seen it happen with many projects, both closed and open. What a waste of people's time.

blowski 9y ago
If it’s trivial and fixes have been offered, why hasn’t it been fixed? Is it controversial?
- js2 9y ago
  I have no idea. The patch is less than a dozen lines. It sat from June 2011 to March 2014 with no action. There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible), but that doesn't explain why it didn't go into 3.3. Some minor feedback (that didn't seem to be a blocker in the first place) was addressed in March 2014 and there it's sat. A new patch then came in in April 2016 which has been completely ignored. I guess my answer is: "there seems to be a lot of friction getting a patch into Python and without a strong advocate, patches sometimes die." I will note that the issue has been classified as an enhancement, not a bug, so maybe that has something to do with it. It still seems like a huge waste of time though.
  - dozzie 9y ago
    > There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible) But it was not backwards compatible. "It works in 2.7" does not mean it works in 2.7.8, but if you try using 2.7.7 it falls apart.
    - js2 9y ago
      Backwards compatible means the patch adds new functionality without breaking the API for existing programs. Of course the new functionality would only work in whichever release it was first shipped. Maybe you’re objecting to it being introduced in a 2.7.x patch release, but that's not without precedent for Python. For example, https://bugs.python.org/issue22960 https://bugs.python.org/issue22960 added a new optional argument to xmlrpclib.ServerProxy and was introduced in 2.7.9.
- pizza234 9y ago
  I have experience on open source projects, and this is the typical open source "limbo" effect. In general, there are different reasons, depending on the project size, and of course the maintainers' personality. On small projects, time is limited. As a consequence, maintainers need to generally take decisions (about merging) in short times. In this case, unless maintainers are very dedicated to expanding the adoption (of developers), or they have very quick decision skills, minor choices will be postponed, possibly indefinitely. On large (/famous) projects, reasons are different. The context is different; in this other end of the spectrum, there is a flurry of patches, and many low quality ones in absolute quantity. Maintainers, and volunteers, again can put a limited/minimal amount of effort. Since on a large project no change is easy, the limited amount of effort is frequently spent on iterating the patch until it's completed or almost, paradoxically causing it to "disappear in the sea of irrelevance" at the right moment. Or maybe it's completed, but not the way a maintainer has in mind, and he has no intention to spending further effort. Of course, those are just factors; I don't imply that all open source projects have [also] these mechanics, but they are frequent reasons why a patch may not be upstreamed even if it's acceptable.
  - js2 9y ago
    I've contributed to a handful of well-known open-source projects over the years, some more, some less. It has always required quite a bit of effort to land patches. That usually gets easier the longer you're involved in a project and the maintainers see that you care about the project and you have a reputation for working with them to contribute quality improvements. I appreciate that a project can't just allow contributors to "throw code over the fence" as it were. There's a delicate balance between maintaining code quality and not accepting everyone's pet feature, moving the project forward, and not turning contributors away. I think sometimes a bit of friction is a good thing insofar as it requires contributors to have some skin in the game. All that said, this really looks like a minor issue here. That's why this one in particular makes me sad. The effort to land it vs effort to fix it is completely out of whack. There ought to be a simpler process for trivial fixes. Yeah, I know sometimes what seems trivial may be hard to assess or ends up introducing regressions. I'm still shedding a tear.
8_hours_ago 9y ago
I came here to post something similar to this. I have seen this happen many times on open source projects, and it is especially depressing for the person who volunteered to write the patch. Going back and forth many times over several months to make small adjustments to your code and never having it committed is very demoralizing. I don't know what the solution is, and it is probably just an inherit flaw with volunteer-run open source projects. Without someone being paid to get the bug count down it's easy for bugs like this to get forgotten about.
- nine_k 9y ago
  I think the answer here could be decentralization. Do not try fixing the canonical module past some reasonable effort. Make a separate version, let interested people `pip install` it. This, of course, does not work with core libraries on which many other standard libraries depend. But its not the case with netrc.
emmelaich 9y ago
FWIW, a workaround is to use the rarely used account field of netrc. You make the machine unique and use the account field to identify the real host. Not a solution for all purposes but for code you're writing yourself it is fine. I use this technique in a Python program which hits REST apis on the same endpoint but under different usernames / privileges / credentials. You can also put things like ssh key, saml, encrypted passwords etc into account and have a fake password for slightly better security. I've seen a proposal for a better netrc format (e.g. integrated with gpg) but I can't find it right now. PS. about the only documentation you'll find on most machines for netrc is the Perl Net::Netrc manual page.

by js2 9y ago

blowski 9y ago

If it’s trivial and fixes have been offered, why hasn’t it been fixed? Is it controversial?

js2 9y ago
I have no idea. The patch is less than a dozen lines. It sat from June 2011 to March 2014 with no action. There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible), but that doesn't explain why it didn't go into 3.3. Some minor feedback (that didn't seem to be a blocker in the first place) was addressed in March 2014 and there it's sat. A new patch then came in in April 2016 which has been completely ignored. I guess my answer is: "there seems to be a lot of friction getting a patch into Python and without a strong advocate, patches sometimes die." I will note that the issue has been classified as an enhancement, not a bug, so maybe that has something to do with it. It still seems like a huge waste of time though.
- dozzie 9y ago
  > There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible) But it was not backwards compatible. "It works in 2.7" does not mean it works in 2.7.8, but if you try using 2.7.7 it falls apart.
  - js2 9y ago
    Backwards compatible means the patch adds new functionality without breaking the API for existing programs. Of course the new functionality would only work in whichever release it was first shipped. Maybe you’re objecting to it being introduced in a 2.7.x patch release, but that's not without precedent for Python. For example, https://bugs.python.org/issue22960 https://bugs.python.org/issue22960 added a new optional argument to xmlrpclib.ServerProxy and was introduced in 2.7.9.
pizza234 9y ago
I have experience on open source projects, and this is the typical open source "limbo" effect. In general, there are different reasons, depending on the project size, and of course the maintainers' personality. On small projects, time is limited. As a consequence, maintainers need to generally take decisions (about merging) in short times. In this case, unless maintainers are very dedicated to expanding the adoption (of developers), or they have very quick decision skills, minor choices will be postponed, possibly indefinitely. On large (/famous) projects, reasons are different. The context is different; in this other end of the spectrum, there is a flurry of patches, and many low quality ones in absolute quantity. Maintainers, and volunteers, again can put a limited/minimal amount of effort. Since on a large project no change is easy, the limited amount of effort is frequently spent on iterating the patch until it's completed or almost, paradoxically causing it to "disappear in the sea of irrelevance" at the right moment. Or maybe it's completed, but not the way a maintainer has in mind, and he has no intention to spending further effort. Of course, those are just factors; I don't imply that all open source projects have [also] these mechanics, but they are frequent reasons why a patch may not be upstreamed even if it's acceptable.
- js2 9y ago
  I've contributed to a handful of well-known open-source projects over the years, some more, some less. It has always required quite a bit of effort to land patches. That usually gets easier the longer you're involved in a project and the maintainers see that you care about the project and you have a reputation for working with them to contribute quality improvements. I appreciate that a project can't just allow contributors to "throw code over the fence" as it were. There's a delicate balance between maintaining code quality and not accepting everyone's pet feature, moving the project forward, and not turning contributors away. I think sometimes a bit of friction is a good thing insofar as it requires contributors to have some skin in the game. All that said, this really looks like a minor issue here. That's why this one in particular makes me sad. The effort to land it vs effort to fix it is completely out of whack. There ought to be a simpler process for trivial fixes. Yeah, I know sometimes what seems trivial may be hard to assess or ends up introducing regressions. I'm still shedding a tear.

8_hours_ago 9y ago

I came here to post something similar to this. I have seen this happen many times on open source projects, and it is especially depressing for the person who volunteered to write the patch. Going back and forth many times over several months to make small adjustments to your code and never having it committed is very demoralizing. I don't know what the solution is, and it is probably just an inherit flaw with volunteer-run open source projects. Without someone being paid to get the bug count down it's easy for bugs like this to get forgotten about.

nine_k 9y ago
I think the answer here could be decentralization. Do not try fixing the canonical module past some reasonable effort. Make a separate version, let interested people `pip install` it. This, of course, does not work with core libraries on which many other standard libraries depend. But its not the case with netrc.

emmelaich 9y ago

FWIW, a workaround is to use the rarely used account field of netrc. You make the machine unique and use the account field to identify the real host. Not a solution for all purposes but for code you're writing yourself it is fine. I use this technique in a Python program which hits REST apis on the same endpoint but under different usernames / privileges / credentials. You can also put things like ssh key, saml, encrypted passwords etc into account and have a fake password for slightly better security. I've seen a proposal for a better netrc format (e.g. integrated with gpg) but I can't find it right now. PS. about the only documentation you'll find on most machines for netrc is the Perl Net::Netrc manual page.