[Python-Dev] Re: Stability and change

[Geoff Gerrietts]

Quoting Guido van Rossum (guido@python.org):
> Before 1.5.2, we *also* hit 6 months with some regularity.  The only
> irregularity was really the 18 month gap between 1.5.2 and 2.0.  We're
> seeing the gap slowly increase, to maybe 8 months for 2.3, but I
> expect that 6-8 months is probably what we'll continue to see.

Which is reasonable, as I've tried to state. But an explicit statement
"We aim for a six-month development cycle with one to two months of
slop" is better than implicitly gathering as much from a review of
documentation release dates (the only handy way I've found to date
releases, short of knowing them off your head).

> > - Be predictable. If we're putting off pain until 3.0, make a guess
> >   when we're going to need to deal with that pain, so we can start
> >   preparing. If 3.0 is 9 months off, that's a lot scarier and more
> >   concerning than if it's 2 years off.
> 
> 3.0 will always be 2 years off. :-)  At least for now, it really is.

Again, reasonable, but not explicitly announced (or if it has been,
it's not vocally announced). I'm not at this point looking for
comfort, having more or less made my bed. It's nice to find warm
sheets, but I'd be stuck with whatever I found. Others are looking for
that kind of comfort, though. While this list might have a good idea
that "deferred for Python 3.0" means "in 2 years, you'll need to
care", I feel like the statement contains a great deal of ambiguity
for those who aren't.

> > - Be explicit about the process. If the process is to stick a fork in
> >   the ham and call it "stable" just before moving on to the next minor
> >   release, then be explicit about that process.
> 
> We are already pretty explicit; there are several PEPs about the
> process.

I think that considering a PEP as explicit explanation of the process
is a lot like expecting cvs log messages to replace Andrew Kuchling's
"What's New" summaries.

Maybe what I mean is not explicit. Maybe I should be hunting for
another word -- how about "forthright"? That's still not ideal, but
the idea is that everyone should know; it should be shouted from the
rooftops.

I think that PEPs are a great tool when they're not fuel for flames
and invective. They're not documentation, though -- they're project
proposals. The audience you reach with a PEP is entirely different
from the audience I'm suggesting you need to reach with this message.

> It depends on the bugfix.  Some modules and subsystems are being
> refactored in order to provide new features, and then bugfixes won't
> port back.  Other modules and subsystems are very stable (some could
> be called stagnant :-) and will have no problem getting bugfixes
> backported.

I think maybe I need to be more concrete about this. The last
/appearance/ of stability -- the last time something looked like a
fixed target -- was 1.5.2, for whatever reason. Lots of people
continue to target 1.5.2, and you can cite a bajillion reasons why
they might.

At first occurance of any problem that may or may not be an
interpreter bug or a standard library defect, the advice given is to
upgrade -- reasonable advice! But that's the suggestion, often without
including a recommendation for which of the newer releases to target.

1.5.2 is obsolescent, and it would be very useful for someone who's
aiming at 2.2 to know how long his or her company could expect to
continue using 2.2 before the first answer to any new problem s/he
might experience was "upgrade".

This is a hard assurance to come by, and a hard promise to make in a
community as dynamic and "scratch my own itch" as python's (or any
open source project, for that matter). Nonetheless, THIS is the
stability benchmark that most corporate clients want a sense of.

> Yes, maybe it can be made to disappear.  Does that mean we need to
> throw the reactionaries on c.l.py a bone?  Is this really all
> politics?  In that case I'm out of here.

I think it's mostly communication, not politics. The two can be
difficult to tell apart, but the former tends to involve telling the
truth, a lot; the latter tends to involve telling fibs, a lot. :)

To more seriously address your concern, my belief is that people who
fear change, fear ambiguity. Managing that fear involves reducing the
ambiguity where you can, and demarking the limits of the ambiguity
where it can't be removed. The best tool for both tasks is explicit,
clear communication. I have tried to identify the places where I see
the largest ambiguities looming. My belief is that if these
ambiguities are controlled by directly addressing them, some portion
of the problems will go away.

I am told that there's a lot of psychological evidence to support this
belief, but I haven't done the lit search and am not especially
inclined to do so without a compelling reason. :)

-- 
Geoff Gerrietts             "Me and my homies, we tag O.D.."
<geoff at gerrietts net>        --Unknown grafitti artist at a party