On Mon, Oct 26, 2009 at 2:12 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
geremy condra writes:
> There is an enormous risk that they are wasting their time. The > goal [of a sandbox] is to save the core devs' time, not those > proposing features.
The core devs' time will be saved by ignoring the sandbox (other than their own features),
Until a feature because quite mature, yes- afterwards, no. That's the point of keeping it separate.
and if it intrudes on them (eg, in the commit notices), they will request that it forcibly be shut up. Cf. the short exchange you had with Nick on the subject of commit notices.
I've already addressed that, see the messages you reference.
ISTM that rather the goal is to ensure that features that would otherwise be overlooked or be blocked because the proponent is unwilling to follow through to the extent required (ie, by a new proposal at the time of ending the moratorium) be given more consideration.
Nope, not the goal.
I don't think a sandbox will help with that, unless it is designed to give incentives and help in producing *better* proposals. Just collecting them in one place is not going to help.
No, it wouldn't. Because that's not the point.
> > It would. But consider the PEP for ipaddr. > > I honestly don't see what this has to do with this proposal.
It's a common pattern of discussion, for both stdlib and core syntax/builtins, and I chose it because it was close to the boundary of approval. I didn't want to choose nonstarters like multiline blocks or trivial suggestions like a warning for "breakless for-else".
> 2) the situation was complicated by recriminations about > the openness of python, the role of the mailinglists vs > the bugtracker, and numerous other issues that we don't > need to go into here.
Are you sure you're not confusing it with the distutils thread(s)?
Pretty sure.
> 3) According to people who know a great deal more about > netmasks than I ever will, the things the author was > unaware of would fill several large books, and even Guido > repeatedly emphasized his lack of knowledge on the subject. > By contrast, the group of core Python developers is > uniquely qualified to talk about changes to the language's > syntax and behavior.
But those are precisely the people whose time you plan to save.
Yes it is.
The only way to save their time is to do less reviewing.
Nope, pretty sure that coming in to do a code review at the end is less time consuming than being involved with a feature from the beginning.
Having an official sandbox might do that by giving the dross a place to collect, so the core devs *never* look at it.<wink>
I like to think that the fact that a patch comes from outside of core will not impact its consideration by that group.
> We're talking about changes to the core language. I would suggest > that the only "apps" possible under those conditions would be > extensive test suites and real-life use.
Yup. Precisely the kind of stuff that happens in real projects, not in sandboxes.
True, and irrelevant. The sandbox I propose is not the existing python sandbox. Choose a different term for it if you want, but anything in it that wants acceptance had better be damned good, and that, in my mind, includes thorough testing.
> > 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. > > I doubt this. Experience suggests that the number of individuals > proposing changes with the technical chops to pull them off is > relatively small,
Sure, but they generally also are core developers. I don't see why an "official sandbox" will be of use to them.
Some core devs may decide to use it to produce features that aren't going to come in under the moratorium, but people outside the core dev group can also use it. Don't assume that the only people with the experience and knowledge to implement such a change are part of the core dev group- especially a couple of years from now. Geremy Condra