[Python-Dev] Re: Stability and change (original) (raw)

Geoff Gerrietts geoff-pdev@gerrietts.net
Mon, 8 Apr 2002 14:51:00 -0700

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.." --Unknown grafitti artist at a party