On 9 Apr 2014 22:11, "Guido van Rossum" <gu...@python.org> wrote: > > On Wed, Apr 9, 2014 at 9:39 PM, Benjamin Peterson <benja...@python.org> wrote: >> >> >> >> On Wed, Apr 9, 2014, at 18:31, Guido van Rossum wrote: >> > I think this is pretty much what Nick Coghlan implied at the summit. >> >> He implied that it's currently the plan or that it should be the plan? > > > As you might understand, we couldn't actually *decide* anything at the summit, but that should be the plan.
Yeah, I think it's on us and other commercial redistributors to figure out how to best meet our long term support commitments to our users, and I personally think that meeting those obligations cost effectively will involve more direct *upstream* involvement in the long term maintenance of the Python 2.7 series. That's largely boring-but-necessary drudgery, and that's the kind of development gap that open source vendors excel at addressing. Still a lot of legwork to get from "I think this is a good way to handle the problem" to actually making it happen, but as the saying goes: if you don't ask, you don't get :) I believe a defined end date for volunteer provided backports actually helps make that case (and the advance warning also provides lead time to hopefully do something about it). > Nick implied that Red Hat has a relevant announcement it will make in two weeks, but wouldn't say more. Kinda wishing I hadn't said anything at all, now - I suspect the temporary vagueness means I'm now building up anticipation that will inevitably lead to disappointment with any actual announcement :( I *can* at least say that we're (all too well) aware of the issues associated with consuming newer dynamic language runtimes on our stable platforms, and we're definitely interested in making it easier for users to deploy and use newer versions of these without harming the consistency and integrity of their system. Assuming we can find an approach (or approaches) that work well for a wide variety of use cases, this should allow us to help reduce the pressure on the developers of upstream Python libraries and frameworks to keep supporting the versions installed system wide in our long term maintenance releases (OpenShift and software collections are a couple of existing efforts that handle some aspects of this issue, but I certainly don't consider the general problem solved at this point). Regards, Nick. > > -- > --Guido van Rossum (python.org/~guido) > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com