3 ms·

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.

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.