Next release

Development matplotlib-devel
1

It's been an unusually bumpy release cycle through no fault of the people involved. We've just been unlucky this time, I guess... :wink:

So -- more bad news:

Julien pointed out a very serious bug this morning, that may warrant another release... The gridlines jump around while panning and zooming. I fully take credit for introducing this bug a few weeks ago trying to fix a log scaling problem. It is now fixed in SVN on 0.98.5 maint and trunk.

Julien also pointed out another bug related to antialiasing which was caused by code that I intended to be experimental (it was committed only to the trunk) but made it into the release. I just want to make a gentle reminder to the hard-working and exhausted release team to please make the next bugfix release from the branch, not the trunk.

Unfortunately, I think because of the seriousness of these bugs, another release should be made asap. I sincerely apologize for the work this causes others. I'm willing to volunteer to do a release to make it up to Charlie and John, but I'm worried, having seen how finicky the build/release process is, that I may not actually help... ;(

As for the release following that -- maybe we should step back and try to find some ways to make it easier. I'm not trying to second guess us here -- I think we're doing a lot of things right, but just want to get a discussion going about whether there's any more tweaks that would be beneficial.

We're doing some good things already -->

1) The release guide in the developer docs

2) John's recent commits of OS-X release tools

3) Using maintenance branches

We may also want to consider -->

4) Automating (scripting) more of the process where possible (I'm sure that's not straightforward... just thinking out loud)

5) Release formal "release candidates" -- IMHO these would be most useful if we expect more people to download and try them than are already tracking SVN. But even without that, it may help find packaging bugs (such as the configobj stuff) before declaring something a "release".

Mike

路路路

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

2

Looks like we are on the same page, since I just hit send in another
thread in the same vein, and have updated the release_guide with
similar suggestions :slight_smile:

I think one other thing that could help here would be to have nightly
builds and sdists. The Makefile for OS X, with some easy
modifications to get snapshots from HEAD, would enable this. With
nightly builds and prominent links on the home page, we will get early
warning on problems that creep into the code base since presumably we
will have more people running from HEAD and exercising the installers
in all the wild and woolly environments that are out there. It would
also force us to have a fully automated checkout/build/test/post
process that will serve us well in the actual releases.

I have access to a win32 and linux machine that are up and on the
network most of the time, and could use these as build/test bots for
those platforms. I have an OS X laptop, but it is not up or on the
network most of the time so is not a good candidate for this. Does
anyone have a suitable OSX 10.5 box on the network with ssh access
that would be suitable to host nightly builds? I could handle all the
code in svn and you could just svn up and point a cron job to some
script in release/osx, or you could give me ssh access to the machine
and I could maintain the job.

As I pointed out in another thread, I would like to have a build
script for win32 in svn that works the same way, but this is a harder
problem, since getting a working build environment is a harder
process. The ideal script would bootstrap the entire build dependency
tree, manipulate setup.cfg automatically, and build the binaries.

路路路

On Mon, Dec 15, 2008 at 8:52 AM, Michael Droettboom <mdroe@...31...> wrote:

4) Automating (scripting) more of the process where possible (I'm sure
that's not straightforward... just thinking out loud)

5) Release formal "release candidates" -- IMHO these would be most
useful if we expect more people to download and try them than are
already tracking SVN. But even without that, it may help find packaging
bugs (such as the configobj stuff) before declaring something a "release".

3

<SNIP>

Hi,

I have access to a win32 and linux machine that are up and on the
network most of the time, and could use these as build/test bots for
those platforms. I have an OS X laptop, but it is not up or on the
network most of the time so is not a good candidate for this. Does
anyone have a suitable OSX 10.5 box on the network with ssh access
that would be suitable to host nightly builds?

I can provide you with ssh access to a decent OSX 10.5 box (Dual Xeon,
8GB) at the University of Washington at Seattle. Just ping me off list
and I can hook you up.

<SNIP>

Cheers,

Michael

路路路

On Mon, Dec 15, 2008 at 7:15 AM, John Hunter <jdh2358@...149...> wrote:

On Mon, Dec 15, 2008 at 8:52 AM, Michael Droettboom <mdroe@...31...> wrote: