On 29/11/2018 22.08, Nathaniel Smith wrote: > On Thu, Nov 29, 2018 at 10:11 AM Christian Heimes <christ...@python.org> > wrote: >> You are assuming that you can convince or force upstream developers to >> change their project and development style. Speaking from personal >> experience, that is even unrealistic for projects that are already >> developed and promoted by officially acknowledged and PSF approved >> Python authorities. >> >> The owners and developers of these projects set their own terms and >> don't follow the same rigorous CI, backwards compatibility and security >> policies as Python core. You can't force projects to work differently. > > Python core does an excellent job at CI, backcompat, security, etc., > and everyone who works to make that happen should be proud. > > But... I think we should be careful not to frame this as Python core > just having higher standards than everyone else. For some projects > that's probably true. But for the major projects where I have some > knowledge of the development process -- like requests, urllib3, numpy, > pip, setuptools, cryptography -- the main blocker to putting them in > the stdlib is that the maintainers don't think a stdlibized version > could meet their quality standards.
It looks like I phrased my statement unclear. CPython's backwards compatibility and security policy isn't necessarily superior to that of other projects. Our policy is just different and more "enterprisy". Let's take cryptography as an example. I contribute to cryptography once in a while and I maintain the official Fedora and RHEL packages. - Alex and Paul release a new version about a day after each OpenSSL security release. That's much better than CPython's policy, because CPython only updates OpenSSL with its regularly scheduled updates. - However they don't release fixes for older minor releases while CPython has multiple maintained minor releases that get backports of fixes. That means I have to manually backport security fixes for cryptography because I can't just introduce new features or API changes in RHEL. The policy is different from CPython's policy. Some aspects are better, in other aspects CPython and cryptography follow a different philosophy. Christian _______________________________________________ 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
