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 ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
