First, I should say out loud that I'm personally embarrassed by how long
it's taken to go from release candidate to a final release in the 1.3.0
cycle. For those that haven't been following along the hold ups have
all been along the lines of showstoppers like "won't install on platform
X", so not just an expectation of absolute perfection. We're still not
100% of the way there, but I hope we're real close now.
Part of this is due to the change to setuptools/distribute, and part of
this is due to procedural things not going as well as they should that
I'd like some help fixing.
To start with setuptools: That brought a lot of changes and kinks that
needed to be worked out, and I'm not surprised that it created a few new
wrinkles. The question in my mind is whether those wrinkles were a
one-off result of the transition to setuptools or that similar things
will reappear in the future. There was the setuptools/distribute
remerge that IMHO was handled and communicated badly upstream, where by
following the explicit directions in the documentation we had a package
that would no longer install. It was hard to find the magic incantation
that would work everywhere, but we got there eventually. Then there was
the issue with pyparsing's upgrade where there's now a non-contiguous
range of version numbers that are compatible with Python 2.x (everything
*but* 2.0.0). It's somewhat fortunate that these happened during the
release candidate cycle so that we could address them quickly. The
theme here? These are problems that get created outside of the control
of the matplotlib team. All of this was brought about because including
copies of our dependencies created its own set of headaches, and
setuptools is the standard solution to that problem, so that `setup.py
install` and tools like `pip` will install the dependencies
automatically. However, in the bad old days, it was at least possible
to ship with some things that worked together, unfortunately, those who
wanted their dependencies external (primarily packagers) were left to
fend for themselves. Even though I was the one who spearheaded the move
to setuptools, I'm wondering whether we shouldn't examine backtracking
on some of this for the 1.4.x release.
The second issue is more one of process. When I make a release
candidate, I announce it here, and Cc all of the packagers of the major
Linux distributions, as well as Christoph and Russell who put together
packages for Windows and Mac respectively. Part of that delegation is
because I don't have installations of all of those platforms, and part
is to spread some of the workload. And most of the time it works really
well -- a big thanks to everyone involved. However, this cycle there
have been a small number of critical bugs discovered in the fifth
release candidate that existed in the first release candidate, which
doesn't give me a lot of confidence that final won't have critical bugs
either. I think some of this will be ameliorated over time as we build
out a more effective continuous integration infrastructure (see MEP19:
we could really use some help on this one), but some of it may have to
do with users being unwilling to test a release until it has the word
"final" attached. How can we get more ordinary users (who may have even
more unusual environments) involved? I also suspect some of it has to
do with the timing in the summer which hits in the middle of vacations
and conference travel for many. We can certainly avoid the summer
months next time. But I don't think it's just about building more time
into the schedule. Let me know if I'm doing something boneheaded ;)
Mike