On 2017-01-21, Brett Cannon wrote:
So the common theme here regardless of whether you agree with Raymond or Victor's approach to development is that we are not getting enough code reviews to go around. To me that's what the systemic issue is that this email is bringing up.
I think there is another issue. What pace of evolution is appropriate for Python 3.x? Python 2.7.x represents an extreme position: bug fixes only. Evolution for 3.x is too fast for some users. It is natural that as Python matures the average user is more interested in a stable langage than in bleeding-edge features. Python 3.x should be compelling to those users if we want to smoothly end-of-life 2.x. If 3.x looks like a "change treadmill" then 2.7 will have a long life.
I don't know how to solve that. Having experimental and stable forks of 3.x seems bad. Incompatible language versions are a drain on the ecosystem. However, a total block of language evolution is also no good.
Maybe we could emulate the Linux kernel releases. I.e. have relatively fast moving development but also choose releases to give long maintenance cycles. Ideally the long term releases would be synchronized with OS distribitions (e.g. Red Hat, Debian, Ubuntu).
The Linux kernel has a strict policy of not breaking user space programs. For Python, a similar rule would be not breaking Python programs. Until 2.x has finally died out, I think we should have an extra conservative policy on incompatible language changes.
Lack of patch reviewers is a major problem. Linux seems to have an advantage of more contributors and that many are paid to work on Linux. As far as I'm aware, there is no core Python developer who works mostly on Python and gets paid for it. So, we have to work with what we have or figure out some way to get people funded.
BTW, thanks for working on the GitHub migration Brett. I think it will help.