On Wed, 27 May 2015 18:34:29 +1000 Nick Coghlan <ncogh...@gmail.com> wrote: > > I'd actually like to pursue a more nuanced view of what's permitted in > maintenance releases, based on a combination of the language moratorium > PEP, and an approach inspired by PEP 466, requiring that every feature > added in a maintenance release be detectable through an attribute check on > a module (with corresponding support in dependency checking tools).
I think this will only complicate the rules and make contributing a specialists' game. Every time you complicate the rules, you add uncertainty, cognitive overhead, opportunities for lengthy discussions, controversies (for an extreme example, think of the Wikipedia process). There is enough boilerplate to care about right now when integrating a patch. > The problem with simply speeding up the release cycle without constraining > the interim releases in some way is that it creates significant pain for > alternate implementations and for downstream redistributors (many of whom > are still dealing with the fallout of the Python 3 transition). At some point, we should recognize our pain is more important than others' when it comes to the fitness of *our* community. I don't see those other people caring about our pain, and proposing e.g. to offload some of the maintenance burden (for example the 2.7 LTS maintenance burden, the maintenance of security branches). For some reason it sounds like we should be altruistic towards people who are not :-) Regards Antoine. _______________________________________________ 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
