geremy condra writes:
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,
Given the degree of decoupling you describe, there's no need for Python to host anything more than a simple CGI for registering remote branches. Probably for the purpose we have in mind the CGI should check that it actually *is* a branch of an official Python branch.
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.
It's a waste of their effort to "play over there" in hopes that their feature will ever be considered. If it's small enough to be considered and approved without a major use case, it probably can be maintained as a patch on the tracker indefinitely.
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,
This is a chunk of management effort to do properly. Take a look at git.kernel.org and tell me which of those branches matter, and to whom. Unless you're a kernel activist, I bet you cannot.
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.
It would. But consider the PEP for ipaddr. That discussion was a total waste of everybody's time because the proponent never put forward a use case in working code for the most controversial feature, making it impossible for anyone to figure out WTF he was thinking. It turns out he wasn't thinking about anything at all, the "feature" was merely an artifact of his implementation, and he didn't understand what others were talking about. When he finally did get around to thinking about what they were talking about, he immediately accepted a sensible proposal, the compromise was accepted with some grumbling, and work can proceed. I forsee lots and lots of those if the only code to review is the implementation of the feature in the officious sandbox. Much better if we can look at the big picture in the context of a real app developed wa-a-ay over there, and a sub-repo containing the relevant branch of Python core. Since it *is* a branch of Python core, you just clone the core, and do "hg merge" and you've got a reviewable implementation.
That's the goal, I'd just also like to have all those improvements centralized for easy review and comparison.
There will be way too many of them to be reviewed at all, let alone easily, if all people have to do is post a branch to an official sandbox.