On Thu, 20 Jan 2000, Guido van Rossum wrote:
... In other words, I'm for putting distutils in the next release, essentially feature-freezing it. Greg Ward, what do you think of that?
Oh, don't get me wrong. I'd like to see it in there for at least all the reasons you cite. But it seems (to me) that it is still pretty alpha. But hey: I'm shooting from the peanut gallery; we need GregW's comments.
Note that if an announcement were made to the effect of "feature freeze on February 15; only bug fixes afterwards," that you would get a lot of people scrambling to submit their pet features. This would be a good way to light some fires, to see what kinds of things get completed (i.e. we may think some things aren't ready or are too far out, put that deadline in and those positions could change...)
I bet you we couldn't complete the import hooks by that date; I consider imputil.py as a nice prototype, but the integration with the C code is still missing. Also the 50% slowdown is a problem I worry about for inclusion a production version. (Plus breakage of everybody else's code who uses or hacks __import__; e.g. have you tested it with rexec?)
hehe... if the static typing is to be deferred, then I'll take that bet! [discussion omitted; too tangental to this thread right now...]
... Good questions. I have to say that I feel reluctant to release any kind of control -- yet at the same time I desperately need help getting trivial stuff checked in.
Reading your comments below, we may be able to help. First, presume that at least one (best would be several) people man the "front lines" for any/all patches and bug reports. The front line can deal with the bug reports, mostly by responding with "go away; enter it into Jitterbug." Patches fall under several catagories, detailed below:
One of the most important time-consuming tasks is quality control: collecting fixes is all well and good, but I routinely reject fixes that superficially look fine,
Conversely, your "lieutenants" (LTs) would filter all ugly-looking patches.
because they are subtly broken,
If the LTs didn't catch these, then you could catch them from the checkin diff email. However, the LTs would reduce the number of broken ones that you would review.
or interfere with other plans,
The LTs may know of this, but if not: you'd catch it at checkin time. The patches would then be backed out, altered, or whatever.
or just because the code looks poorly written.
The LTs would definitely catch this. If the style was *still* not up to snuff, I'd have to believe it would only be in minor ways that you could then touch up at your leisure.
I also spend a lot of testing before I check things in;
Done by the LTs.
running the standard test suite is a good safeguard against general breakage,
Ditto.
but you really have to play with the code affected by the change before you can know that it works as advertised.
Ditto.
My work attitude here means that what gets checked in is generally rock solid, and that helps Python's reputation; but it is very costly...
Based on my responses, I would venture to state that a group of LTs would manage to keep the Python core rock solid, except for: 1) subtle breakages that require your broader knowledge of Python 2) changes that "go against the plan" (and the LTs were ignorant of it) 3) minor format issues You would still review checkins, but the number of reviews would drop since the (obvious) crap has been eliminated. #1 is based on your *broad* knowledge of Python; I presume the LTs would be your match on various subsets of Python. By keeping the LTs well-informed, #2 could be nearly eliminated. #3 isn't that big of a deal, as I think your desired style is relatively well-known and the LTs would simply endeavor to match existing style. You could avoid a lot of testing; you would probably be inclined to do testing of items that you find dubious, but still this would be a reduction. ===== That may be an answer to the checkin problem. How about actual snapshots, alphas, betas, releases, and accompanying notes/news/readme files? I presume your LTs could run the alpha and beta aspects, but you would still issue final releases. Does your mail volume need to be reduced? (I think this has been asked before) Specifically, would patches@python.org (and similar targets) need to be established? (I would think so, as a matter of course, with the expectation that some patches would still end up with you and need to be bounced to patches@) Cheers, -g -- Greg Stein, http://www.lyra.org/