On Sun, Oct 25, 2009 at 3:01 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
geremy condra wrote:
On Sun, Oct 25, 2009 at 1:33 AM, Nick Coghlan <ncoghlan@gmail.com> wrote: I'm a little unclear on what you're driving at here- my goal is to keep these projects off the minds of the core devs until they're about ready to go, to make it easy for all the implementors to carefully assess both the features themselves and the code used to implement them as they near that point, and to make certain that there is a common point of reference for the debate over inclusion afterwards. In other words, not specifically to remove python-dev from the process, but rather to allow it to spend its time more productively elsewhere until it can be usefully spent there.
Having an "official sandbox" is completely irrelevant (and probably counterproductive) if core development is happening in a DVCS.
I don't see any evidence for either of these claims, and IMO the argument that somehow allowing people to "go play over there" until they've got something that could seriously be considered for merging is going to slow down core development is a little silly.
If people want to experiment, they will be able to experiment by branching into their own repository. Trying to create an "official sandbox" (or, more likely, use the existing sandbox) defeats the whole point of the exercise, since it just brings the CPython admins back into the loop and will generate a pile of irrelevant traffic on python-checkins.
I don't see the sandbox working this way. I see it being somewhat more separated from the official core, probably to the point where it wouldn't generate checkin messages and hopefully to the point where it wouldn't require a dev to start a publicly viewable branch. This also avoids the problem of having to go through a kajillion different places to see what kinds of proposals have active support or are close to completion and which aren't, which should help to discourage people from duplicating effort, as well as giving the various implementors more advance warning on what might be coming down the pipe.
In short, a moratorium that said "we won't accept things into trunk, but you can still pester us to add things to our official sandbox" would be a pointless exercise.
You see the difficulty of occasionally reviewing a substantive, testable proposal for a language change as being enough to outweigh the advantages Guido has attributed to the moratorium? And here I was thinking that adopting a code-first-jaw-later approach would save the devs time.
Moving to a DVCS, putting a core language change moratorium in place for a few years, then looking to see what improvements have been developed outside the core tree as the moratorium is running down (and what feedback has been received over that time) would be far more sensible.
That's the goal, I'd just also like to have all those improvements centralized for easy review and comparison. Geremy Condra