What Mark is advocating is a rough lock-step release cycle amongst upstream projects that are core, upstream applications, and Linux distributions. The idea is that Python, GCC, etc. all release in the same month their next versions, applications follow a month later, and then finally Linux distributions a month after that. The idea is that the Linux distros would then all ship with the same version of their upstream projects (e.g., everyone would ship with Python 2.5.x in 2008, 2.6.x in 2009, etc.).
I have to admit, from a Python developer's perspective, that does sound nice. Because the Linux distributions and their users tend to be a large chunk of the Python users out there, we see bug reports on the various versions of Python that each major distro is shipping. That can be annoying as there is a chunk of time where we can still get reports a whole version behind of what is stable. If a nice chunk of our users moved over to the same version each year the bug reports would be against a consistent version and thus hopefully lead less extraneous bugs being reported about older versions.
Now I don't think a one month spacing is enough for everyone to do thorough testing. I suspect spacing it out over six months instead of three might work out better (but since Python has hardly any external dependencies this is just from outside observation and not experience).
Locking down releases might also help us schedule sprints. If we said we would do major releases every September, and minor releases September and March then everyone would know when to submit language proposals, what they must hit for something to make it in, when python-dev will most likely need extra help to finish that final push to beta, etc. We would then know when betas would hit, and thus have sprints three months before so that there is enough time for crazy ideas that come up at the sprints to be coded, implemented, vetted, and tested before the beta hits.
There are a couple of questions that need to be answered if this were to happen. One is whether python-dev has the discipline to pull this off? I say yes as long as we have a release manager that is willing to take the hard line on reverting patches that don't make the time cut-off. So far that has worked this year with our monthly releases.
Another question is whether we are structured for this kind of thing? Releases take a couple of hours from several people. Now having a regular schedule would suggest that it would be easier for these people as they would know when to expect the big push to hit.
Lastly, do we have the infrastructure and tools? Merging between the trunk and a branch is a pain. But if we really start to hold up features because they don't reach a release point means people really should start all work in branches and expect to miss a release instead of expecting to actually make their target and only shift to a branch if they miss. If this isn't done code goes stale thanks to the length of time it takes for Python to go from beta to a final release (this is why I shifted my importlib work to bzr since I expected I would miss 3.0).
If the final releases for 2.6 and 3.0 go well I might try to push for a regular release schedule for Python.
