Re: [matplotlib-devel] Next release

On Mon, Dec 15, 2008 at 8:52 AM, Michael Droettboom <md...@st...> 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".

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 :-)

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.