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

Skip Montanaro skip@pobox.com
Wed, 10 Apr 2002 09:16:24 -0500 

SM> If most people don't test out early releases now, Tim's been wasting
SM> his time generating all those installers.

Jeremy> Here you say: Few people download and test development releases.

SM> The only way a significant change in the development model is going
SM> to work is if the effort necessary to generate micro releases drops
SM> drastically.

Jeremy> Here you say: Let's do more development releases.

Jeremy> Why?

I think I need to write a PEP. I suppose I would have by now, but it seems that most of my mails on this subject are falling on deaf ears.

There is perception and there is reality. I believe the reality is that Python is pretty stable. There seems to be a perception outside of the python-dev community that it is not. In large measure this thread has been more about what to do about perceived instability than actual instability.

Way back on April 8th, I sent this note to python-dev:

The problem with simply dealing off the top of the CVS deck is that it
provides no way to conclusively state that the current CVS head is
either more functionally complete or more bug-free than an earlier CVS
head.  Hopefully releases will be must smaller efforts than they
currently are.  Pulling away from SF for releases will certainly help.
If a micro release on the development branch can asymptotically approach

    * create a baseline named devel-2.N.x
    * drop a tarfile onto www.python.org
    * send out an email

I think you could probably justify making releases on that branch every
month or so.  Releases on the stable branch would probably occur less
frequently (only when a sufficient number of bug fixes had accumulated
or a particularly serious bug fix was applied to the branch) and be a
bit more involved (maybe involving creation of a Windows installer).

Above and beyond the notion of complexity or technical superiority of
different development models, I think you need to realize a positive PR
advantage from a change in development models.  If you could produce a
table like

    Version          Bugs fixed
    -------          ----------
    2.4.1                47
    2.4.2                32
    2.4.3                12
    2.4.4                 3

you would go a long way toward arguing that "stable" branches are really
getting more stable.  Similarly, such a table on the development branch
might help developers decide if the development branch is stable enough
to fork.

You need to make measurements that demonstrate to people that your code base is getting more stable, if only for PR purposes. Associating those metrics with specific release points would, I think, provide more confidence in those numbers. It's cheap to add a new tag to CVS. It's not much more expensive to dump a tarball associated with that tag. That's all I'm really suggesting you do along the development branch. Hell, you won't even need a release manager. The PLabs gang could announce they are going to take a snapshot Friday, ask for a freeze at 10AM EST, have their weekly staff meeting, create the tag at noon, and have a tarball on the website by 12:30, including updating a table on the as-yet-nonexistent /dev/downloads page.

Even if not a single soul downloads and builds a particular snapshot, creating such snapshots helps because they provide you with static points in the CVS repository from which to make measurements. They are, in effect, the X axis values of a plot of whatever other measurements you make on the code base (number of modules, lines of code changed, etc). "You" here means "you, the overall community". I'm not suggesting that PythonLabs take on the extra burden of making a bug of measurements. Just provide the tickmarks for the graph.

Skip