[Python-Dev] Python 1.6 timing

[Greg Stein]

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/