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

Geoff Gerrietts geoff-pdev@gerrietts.net
Mon, 8 Apr 2002 12:58:47 -0700

Quoting Guido van Rossum (guido@python.org):

I very muich doubt that the corporate users who are currently worried about the fast pace of change are interested in any particular feature, and I don't think that any backported feature is going to make that previous version more popular amongst managers with decision power. The question in front of them is, "should we use Python or not", not "should we use Python 2.1". To answer that question, they want to perceive "Python" as stable, not "Python 2.1".

I think, as this discussion slowly seems to be winding down and my list subscription goes through, that I can finally contribute something.

One of the points I've seen brought across is that "stable python" needs to be more widely acclaimed as such. The example seems to be the 2.1.3 release, or the 2.1.* series in general. I agree with this, wholeheartedly.

The remains of the discussion seems to circle around how to number or manage the changes so that it's easier to know how things are developing. To this, I think that picking a scheme is a lot less important than documenting what that scheme means to the people who are using it. Maybe we can cash in on some of the ideas put forward by other people, maybe we can't, maybe we shouldn't. What's important is not how we do it, but that we're explicit about what we do.

The remains of this note are going to be long-winded, so if you're prone to start skimming, now would be a good time .

BACKGROUND (where I'm coming from) A little background -- I'm part of a company (at my other email address) that views Python as part of their competitive advantage. We engage in weekly rolls into production, with product cycles that last between two and four weeks. Three of us write python regularly; four of us write DTML and HTML. Management duties, release scheduling, release management, deployment, and site maintenance responsibilities are scattered liberally among this crew of seven. We do a lot of business at this site, which makes those scattered responsibilities fairly time-consuming for some of us.

Despite this, we manage to maintain the aggressive schedule, which has in turn enabled us to bring in big partnerships and close substantial deals with a very small core of engineers holding it all together.

In many ways, we are the sort of story that serves as an advertisement for Python (though you should stop well short of holding up our code as examples, if you know what I mean).

On the other hand, a full overhaul of the site to advance to a new version of Python is a substantial project. Between the dependencies on third-party products, the extensive customizations we've had to make, the QA overhead that goes into a full site regression, and the management overhead that goes into tracking down all the bits and pieces -- that's about a month-long project, though we might be able to fit it into 3 weeks.

This puts us into the "conservative" camp. For some time now, we have regarded it easier to steer around, work around, or hack around bugs in 1.5.2 than to upgrade. We've backported a fix or two. It's still not enough. Recently, we've agreed to upgrade, and managed to secure executive permission to take a 3 week cycle (scattered over the next couple months) to do the updating work.

My situation may be atypical, but I think that we're the sort of operation that the python community doesn't really want to alienate.

THOUGHTS ON STABILITY When I use python for myself, I prefer to use 2.2, because I prefer to stay current. When I develop python for a wider audience, I plan for 1.5.2, because that's what I'm pretty sure I can count on people to have available. I can speculate why this is so, but it would be speculation.

When I looked at upgrading to the 2.* series of python interpreters, I wasn't sure where to target. 2.0 is for all intents and purposes a dead end. 2.1 is seeing some active bugfix development, but there's no visible commitment from the community to continue that trend. In fact, when the topic gets broached, it more often than not gets shot down with "not likely, who would want to waste their time on doing that?" or some variation therof. 2.2 appears stable, but there's a bugfix release in the works that hasn't (as far as I know) been made official yet. In other words, none of the 2.* series appeared like particularly attractive targets to shoot at, because all of them appeared to be unsuitable for the needs of our organization. I decided to shoot for 2.2, because it's hard to tell when we'll be able to do the upgrade again, and I wanted to solve as many problems as could be solved, now. It appears that may have been a bad choice, given progress with 2.1.3.

People talk about a 6 month gap between releases, but I'm not sure anyone recognizes that timeframe as "average" yet. You can have an average with only two measurements, but it really takes three to make a series, and the gap between 1.5.2 and 2.0 was considerably longer than 6 months. The point here is that when you adopt any given minor version of python, you have no idea how long you have before you're obsolescent. Six months is reasonable, if that is in fact what we continue to hit. But being predictable is more important to "the conservative crowd" than any particular interval could be.

In conclusion, I think that what "the conservatives" are looking for is really quite easy to provide. I summarize them as:

The perceived problem with change being too rapid may be just that, a perceived problem. With adequate and careful communication, the problem may disappear entirely. It may not, but we can always dream. :)

Anyway, that's about all I can contribute, after thinking long and seriously about what I feel like our company needs, and trying to ignore the specific details of implementation. I hope it's helpful.

Thanks, --G.

-- Geoff Gerrietts http://www.gerrietts.net/ "Politics, as a practice, whatever its professions, has always been the systematic organization of hatreds." --Henry Adams