On Nov 26, 2015 4:53 PM, "Nick Coghlan" firstname.lastname@example.org wrote:
On 27 November 2015 at 03:15, Barry Warsaw email@example.com wrote:
Likewise in Ubuntu, we try to keep deviations from Debian at a minimum,
document them when we must deviate. Ubuntu is a community driven
while Canonical itself has customers, it's much more likely that
about the Python stack comes from ordinary users. Again, my personal
to make Python on Ubuntu a pleasant and comfortable environment, as
installing from source as possible, consistent with the principles and policies of the project.
I'd strongly agree with that description for Fedora and softwarecollections.org, but for the RHEL/CentOS system Python I think the situation is slightly different: there, the goal is to meet the long term support commitments involved in being a base RHEL package. As the nominal base version of the package (2.7.5 in the case of RHEL 7) doesn't change, there is naturally going to be increasing divergence from the nominal version.
I think the goal in rhel/centos is similar, actually. The maintenance burden for non upstream changes has been acknowledged as a problem to be avoided by rhel maintainers before. The caveat for those distributions is that they accumulate more *backports*.
However, backports are easier to maintain than non upstream changes. The test of the upstream community helps to find and fix bugs in the code; the downstream maintainer just needs to stay aware of whether fixes are going into the code they've backported.
I tried to go down the "upstream first" path with a properly supported "off switch" in PEP 476, and didn't succeed (hence the monkeypatch compromise). It sounds like several folks would like to see us revisit that decision, though.
That's the rub. If there's now enough support to push this upstream I think everyone downstream will be happier. If it turns out there's still enough resistance to keep it from upstream then I suppose you cross that bridge if it becomes necessary.