[Python-Dev] Re: Stability and change

[Geoff Gerrietts]

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 <wink>.

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:

- 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.

- 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.

- Be explicit about obsolescence. If things in 2.3 or 3.0 or X.Y are
  shaping up to be so different that bugfixes won't be back-portable,
  then identify that fact early -- and make an effort to provide a
  reasonable target for people to upgrade to, as soon as possible.

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 <geoff at gerrietts dot net>     http://www.gerrietts.net/
 "Politics, as a practice, whatever its professions, has always been the 
          systematic organization of hatreds." --Henry Adams