[Python-Dev] Re: Stability and change

[Skip Montanaro]

    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