[Python-Dev] Thoughts on stdlib evolvement

Stephen J. Turnbull stephen at xemacs.org
Sat Jun 11 18:01:09 CEST 2005


>>>>> "Gustavo" == Gustavo Niemeyer <gustavo at niemeyer.net> writes:

    Gustavo> An issue to consider about this is that maintainers (not
    Gustavo> talking about you or anyone else specifically) have
    Gustavo> different concepts of stability, and while it may seem
    Gustavo> perfectly ok to refactor external modules between two
    Gustavo> stable releases, doing so in the standard library would
    Gustavo> spread fear and "python is so untrustful" feelings.

This simply hasn't been a problem in XEmacs's equivalent to the
standard library.  In fact, the library modules tend to be
more stable than the core, for several reasons.  One important one is
that the modules we distribute are not necessarily the bleeding edge.
In particular, we try to keep up (within a couple weeks) with bugfixes
to stable lines, but often lag several months after a major refactoring.

This multitrack approach does involve some extra administrative work,
but the burden on the core team is minimal.  Most modules are managed
by volunteers who do not feel able to contribute to the core (and
often not to the coding of "their" module), but are very pleased to be
able to contribute in this way.  They are usually far more competent
than the core developers to judge when new features are sufficiently
attractive and stable to warrant updating to a refactored version,
too.  They tend to be more conservative than the module's lead
maintainer, too.

I will grant that XEmacs deserves (and probably has<wink>) a lower
trust rating than Python, but that is due to flaws in the _core_, not
in the package management.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.


More information about the Python-Dev mailing list