release strategy, and the role of v0_98_5_maint

Eric_Firing2 · April 5, 2009, 11:38pm

It is not always clear what should go in the 0.98.5 maintenance branch. For example, is the _png.cpp patch by Tobias, committed by Andrew, a bug fix or a new feature? I would have said the latter, but I can see arguments either way.

More generally, how long do we need to keep updating this maintenance branch?

And is there a release schedule in mind? Any prospect of more thoroughly automating official releases and of adding svn snapshot releases? And of following numpy's buildbot example?

I don't think I can help with any of this; I am just casting about to see if there might be someone on the list who is interested and can break loose some time.

Eric

_John_Hunter · April 7, 2009, 11:41am

It is not always clear what should go in the 0.98.5 maintenance branch.
For example, is the _png.cpp patch by Tobias, committed by Andrew, a
bug fix or a new feature? I would have said the latter, but I can see
arguments either way.

More generally, how long do we need to keep updating this maintenance
branch?

I have been meaning to do a release from the branch for some time, but
haven't gotten it done. Charlie, if you are out there and have some
time, please forge ahead. Otherwise, I will devote some time to it
next week when I am back from vacation.

In general, only very clear bugfixes which are unlikely to result in
"surprise" breakages should go in. The _png patch, though a bug fix,
has more of the feel of a feature enhancement, and given its
complexity, should probably not go in to the branch unless someone
makes a compelling case (though I am very excited to see it go in to
the trunk).

As soon as we get the branch release out, I would like to push to get
a trunk release out as soon as it is ready, and all the remaining
outstanding features that people are working on get put in. Then the
trunk will become the branch, and the branch will be finished, either
removed or allowed to linger for a while and then removed. But I
think this should be the last release of this branch, one suitable for
debian and other packagers who release infrequently because it should
be very stable at this point.

And is there a release schedule in mind? Any prospect of more
thoroughly automating official releases and of adding svn snapshot
releases? And of following numpy's buildbot example?

I don't think I can help with any of this; I am just casting about to
see if there might be someone on the list who is interested and can
break loose some time.

We are not that far away, at least for src snapshots, os x binaries,
and the docs. The windows binary would take some work, as would a
linux binary, eg a debian package. I am definitely for it, but one or
more of us will have to step up and push it through.

JDH

···

On Sun, Apr 5, 2009 at 6:38 PM, Eric Firing <efiring@...229...> wrote:

Andrew_Straw5 · April 7, 2009, 4:06pm

John Hunter wrote:

In general, only very clear bugfixes which are unlikely to result in
"surprise" breakages should go in. The _png patch, though a bug fix,
has more of the feel of a feature enhancement, and given its
complexity, should probably not go in to the branch unless someone
makes a compelling case (though I am very excited to see it go in to
the trunk).

OK, I wasn't sure about it when I put it in. Shall I back it out?

We are not that far away, at least for src snapshots, os x binaries,
and the docs. The windows binary would take some work, as would a
linux binary, eg a debian package.

FWIW, the Debian packagers will want to make their own .debs from the
source package.

Also note that the Windows binaries may take more effort than normal --
Python 2.6 is built with a different MS compiler than before.

Eric_Firing2 · April 7, 2009, 5:52pm

John Hunter wrote:
[...]

And is there a release schedule in mind? Any prospect of more
thoroughly automating official releases and of adding svn snapshot
releases? And of following numpy's buildbot example?

I don't think I can help with any of this; I am just casting about to
see if there might be someone on the list who is interested and can
break loose some time.

We are not that far away, at least for src snapshots, os x binaries,
and the docs. The windows binary would take some work, as would a
linux binary, eg a debian package. I am definitely for it, but one or
more of us will have to step up and push it through.

For snapshots, I think that packages are needed only for OS X and Windows. Anyone who is going to be running snapshots on linux should be able to build from a tarball or svn. (And they should be installing in /usr/local or a private location.) The only step that might be nice to make that easier would be to list the package dependencies for common distros--that is, not just in generic form, but the actual names.

Eric

_Sandro_Tosi3 · April 7, 2009, 9:02pm

I'm ready and waiting for a shiny new release to give our beloved
Debian users a package to install

In unstable we have a "rather old" release, 0.98.3, since I was asked
to not upload 0.98.5.2 to the main audience (it's now in experimental,
JFTR).

Cheers,

···

On Tue, Apr 7, 2009 at 18:06, Andrew Straw <strawman@...36...> wrote:

John Hunter wrote:

We are not that far away, at least for src snapshots, os x binaries,
and the docs. The windows binary would take some work, as would a
linux binary, eg a debian package.

FWIW, the Debian packagers will want to make their own .debs from the
source package.

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

_Charlie_Moad · April 8, 2009, 1:14pm

I might be able to squeeze some time in this weekend. I am not
thrilled about the new visual studio requirements, nor do I have
access to it. I know John started a build script for OSX and I have
been meaning to try something similar for mingw. Is anyone opposed to
creating the official releases with mingw?

- Charlie

···

On Tue, Apr 7, 2009 at 5:02 PM, Sandro Tosi <morph@...12...> wrote:

On Tue, Apr 7, 2009 at 18:06, Andrew Straw <strawman@...36...> wrote:

John Hunter wrote:

We are not that far away, at least for src snapshots, os x binaries,
and the docs. The windows binary would take some work, as would a
linux binary, eg a debian package.

FWIW, the Debian packagers will want to make their own .debs from the
source package.

I'm ready and waiting for a shiny new release to give our beloved
Debian users a package to install

In unstable we have a "rather old" release, 0.98.3, since I was asked
to not upload 0.98.5.2 to the main audience (it's now in experimental,
JFTR).

Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

_william_ratcliff · April 8, 2009, 2:17pm

I’d actually prefer it ;>

···

On Wed, Apr 8, 2009 at 9:14 AM, Charlie Moad <cwmoad@…149…> wrote:

I might be able to squeeze some time in this weekend. I am not

thrilled about the new visual studio requirements, nor do I have

access to it. I know John started a build script for OSX and I have

been meaning to try something similar for mingw. Is anyone opposed to

creating the official releases with mingw?

Charlie

On Tue, Apr 7, 2009 at 5:02 PM, Sandro Tosi <morph@…12…> wrote:

On Tue, Apr 7, 2009 at 18:06, Andrew Straw <strawman@…36…> wrote:

John Hunter wrote:

We are not that far away, at least for src snapshots, os x binaries,

and the docs. The windows binary would take some work, as would a

linux binary, eg a debian package.

FWIW, the Debian packagers will want to make their own .debs from the

source package.

I’m ready and waiting for a shiny new release to give our beloved

Debian users a package to install

In unstable we have a “rather old” release, 0.98.3, since I was asked

to not upload 0.98.5.2 to the main audience (it’s now in experimental,

JFTR).

Cheers,

–

Sandro Tosi (aka morph, morpheus, matrixhasu)

My website: http://matrixhasu.altervista.org/

Me at Debian: http://wiki.debian.org/SandroTosi

This SF.net email is sponsored by:

High Quality Requirements in a Collaborative Environment.

Download a free trial of Rational Requirements Composer Now!

http://p.sf.net/sfu/www-ibm-com

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

This SF.net email is sponsored by:

High Quality Requirements in a Collaborative Environment.

Download a free trial of Rational Requirements Composer Now!

http://p.sf.net/sfu/www-ibm-com

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

_John_Hunter · April 8, 2009, 3:16pm

I might be able to squeeze some time in this weekend. I am not
thrilled about the new visual studio requirements, nor do I have
access to it. I know John started a build script for OSX and I have
been meaning to try something similar for mingw. Is anyone opposed to
creating the official releases with mingw

None here.

Thanks,
JDH

···

On Apr 8, 2009, at 9:14 AM, Charlie Moad <cwmoad@...149...> wrote:

- Charlie

On Tue, Apr 7, 2009 at 5:02 PM, Sandro Tosi <morph@...12...> wrote:

On Tue, Apr 7, 2009 at 18:06, Andrew Straw <strawman@...36...> >> wrote:

John Hunter wrote:

We are not that far away, at least for src snapshots, os x binaries,
and the docs. The windows binary would take some work, as would a
linux binary, eg a debian package.

FWIW, the Debian packagers will want to make their own .debs from the
source package.

I'm ready and waiting for a shiny new release to give our beloved
Debian users a package to install

In unstable we have a "rather old" release, 0.98.3, since I was asked
to not upload 0.98.5.2 to the main audience (it's now in experimental,
JFTR).

Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

------------------------------------------------------

Eric_Firing2 · April 8, 2009, 6:59pm

Charlie Moad wrote:

I might be able to squeeze some time in this weekend. I am not
thrilled about the new visual studio requirements, nor do I have
access to it. I know John started a build script for OSX and I have
been meaning to try something similar for mingw. Is anyone opposed to
creating the official releases with mingw?

As long as it works, I would greatly prefer it. A build script would be great.

Eric

_Charlie_Moad · April 10, 2009, 7:06pm

0.98.6 only?

···

On Wed, Apr 8, 2009 at 2:59 PM, Eric Firing <efiring@...229...> wrote:

Charlie Moad wrote:

I might be able to squeeze some time in this weekend. I am not
thrilled about the new visual studio requirements, nor do I have
access to it. I know John started a build script for OSX and I have
been meaning to try something similar for mingw. Is anyone opposed to
creating the official releases with mingw?

As long as it works, I would greatly prefer it. A build script would be
great.

Eric

_Charlie_Moad · April 10, 2009, 7:19pm

Sorry, I guess 0.98.5.3 looking at the branch. No need for a 0.91
update though?

···

On Fri, Apr 10, 2009 at 3:06 PM, Charlie Moad <cwmoad@...149...> wrote:

0.98.6 only?

On Wed, Apr 8, 2009 at 2:59 PM, Eric Firing <efiring@...229...> wrote:

Charlie Moad wrote:

I might be able to squeeze some time in this weekend. I am not
thrilled about the new visual studio requirements, nor do I have
access to it. I know John started a build script for OSX and I have
been meaning to try something similar for mingw. Is anyone opposed to
creating the official releases with mingw?

As long as it works, I would greatly prefer it. A build script would be
great.

Eric

Michael_Droettboom · April 10, 2009, 7:28pm

IMHO 0.91 is probably retired at this point. There are some bugfixes on that branch since the last release, but there's been no activity since 10-05-2008.

Mike

Charlie Moad wrote:

···

Sorry, I guess 0.98.5.3 looking at the branch. No need for a 0.91
update though?

On Fri, Apr 10, 2009 at 3:06 PM, Charlie Moad <cwmoad@...149...> wrote:


0.98.6 only?

On Wed, Apr 8, 2009 at 2:59 PM, Eric Firing <efiring@...229...> wrote:


Charlie Moad wrote:


I might be able to squeeze some time in this weekend. I am not
thrilled about the new visual studio requirements, nor do I have
access to it. I know John started a build script for OSX and I have
been meaning to try something similar for mingw. Is anyone opposed to
creating the official releases with mingw?


As long as it works, I would greatly prefer it. A build script would be
great.

Eric

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

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

system · April 10, 2009, 8:06pm

I think so. We can keep 0.91 around in case anyone needs it and a critical bug fix comes in, but I think we should get the final bugfix on 0.98 out with this release and then focus on the trunk for the next release.

Thanks,
JDH

···

On Apr 10, 2009 2:06pm, Charlie Moad <cwmoad@…149…> wrote:

0.98.6 only?

_Charlie_Moad · April 11, 2009, 12:40am

Python2.6 went fairly clean. I had to modify setupext.py a little to
account for tcltk8.5 and add the tcltk8.5 headers to the win32_static
distribution.

I am running into an error when importing matplotlib though. I'll
poke around but would appreciate extra eyes.

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python26\lib\site-packages\matplotlib-0.98.5.3_r7035-py2.6-win32.egg\matplotlib\pyplot.py
", line 6, in <module>
    from matplotlib.figure import Figure, figaspect
  File "c:\python26\lib\site-packages\matplotlib-0.98.5.3_r7035-py2.6-win32.egg\matplotlib\figure.py
", line 17, in <module>
    import artist
  File "c:\python26\lib\site-packages\matplotlib-0.98.5.3_r7035-py2.6-win32.egg\matplotlib\artist.py
", line 5, in <module>
    from transforms import Bbox, IdentityTransform, TransformedBbox,
TransformedPath
  File "c:\python26\lib\site-packages\matplotlib-0.98.5.3_r7035-py2.6-win32.egg\matplotlib\transform
s.py", line 34, in <module>
    from matplotlib._path import affine_transform
ImportError: DLL load failed: The specified procedure could not be found.

- Charlie

···

On Fri, Apr 10, 2009 at 4:06 PM, <jdh2358@...149...> wrote:

On Apr 10, 2009 2:06pm, Charlie Moad <cwmoad@...149...> wrote:

0.98.6 only?

I think so. We can keep 0.91 around in case anyone needs it and a critical
bug fix comes in, but I think we should get the final bugfix on 0.98 out
with this release and then focus on the trunk for the next release.

Thanks,
JDH

Matt_Knox · April 11, 2009, 1:07am

ImportError: DLL load failed: The specified procedure could not be found.

This is most likely due to the localtime problem when building extensions
with mingw. I encountered this too when trying to get the scikits.timeseries
module ready for a release. I implemented a work around mentioned on the
python users list a while ago, you can take a look here:

http://svn.scipy.org/svn/scikits/trunk/timeseries/scikits/timeseries/src/c_dates.c

lines 2585 - 2609

Basically, if you use localtime, time or time_t anywhere in your extension
and compile your extension with mingw for python 2.6, it will fail to
import. This is due to some conflict with mingw and visual studio 2008, the
details of which I am not really familiar with, I just know the work around
works.

- Matt

···

--
View this message in context: http://www.nabble.com/release-strategy%2C-and-the-role-of-v0_98_5_maint-tp22900147p22996892.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Andrew_Straw5 · April 11, 2009, 2:08am

Charlie Moad wrote:

I am running into an error when importing matplotlib though. I'll
poke around but would appreciate extra eyes.

ImportError: DLL load failed: The specified procedure could not be found.

Hi Charlie, we've been batting this one around on MPL-users for a little
while... still no resolution though. See the thread started by Lorenzo
Di Gregorio "matplotlib._path failed on windows build for Python 2.6".

-Andrew

_Charlie_Moad · April 11, 2009, 2:15am

I found that thread not too long ago and dug up the tool John mentioned.

http://www.dependencywalker.com/

Looks like our friend "msvcrXX" (msvcr90 for py2.6) is back. I am
removing the link from distutils right now and giving it a try.

- Charlie

···

On Fri, Apr 10, 2009 at 10:08 PM, Andrew Straw <strawman@...36...> wrote:

Charlie Moad wrote:

I am running into an error when importing matplotlib though. I'll
poke around but would appreciate extra eyes.

ImportError: DLL load failed: The specified procedure could not be found.

Hi Charlie, we've been batting this one around on MPL-users for a little
while... still no resolution though. See the thread started by Lorenzo
Di Gregorio "matplotlib._path failed on windows build for Python 2.6".

-Andrew

_Charlie_Moad · April 11, 2009, 2:20am

Yeah, that worked. Removed the link from
distutils/cygwinccompiler.py. I didn't get the error from python 2.4
or 2.5, but that's probably because I have had them installed for a
while and these dll's have been installed from other modules. I'll
try to get some binaries posted soon.

- Charlie

···

On Fri, Apr 10, 2009 at 10:15 PM, Charlie Moad <cwmoad@...149...> wrote:

I found that thread not too long ago and dug up the tool John mentioned.

http://www.dependencywalker.com/

Looks like our friend "msvcrXX" (msvcr90 for py2.6) is back. I am
removing the link from distutils right now and giving it a try.

- Charlie

On Fri, Apr 10, 2009 at 10:08 PM, Andrew Straw <strawman@...36...> wrote:

Charlie Moad wrote:

I am running into an error when importing matplotlib though. I'll
poke around but would appreciate extra eyes.

ImportError: DLL load failed: The specified procedure could not be found.

Hi Charlie, we've been batting this one around on MPL-users for a little
while... still no resolution though. See the thread started by Lorenzo
Di Gregorio "matplotlib._path failed on windows build for Python 2.6".

-Andrew

_Charlie_Moad · April 11, 2009, 2:36am

http://drop.io/tvuqe3o

Please test these windows builds. I committed a change to set
tcltk8.5 flags for python 2.6 and I also uploaded a modified
win32_static.zip file. Could someone please replace the previous one
with the newer version? It includes the tcltk8.5 headers needed for
the build. If these builds test out well I'll proceed with the whole
slew of files for the release later this weekend.

- Charlie

···

On Fri, Apr 10, 2009 at 10:20 PM, Charlie Moad <cwmoad@...149...> wrote:

Yeah, that worked. Removed the link from
distutils/cygwinccompiler.py. I didn't get the error from python 2.4
or 2.5, but that's probably because I have had them installed for a
while and these dll's have been installed from other modules. I'll
try to get some binaries posted soon.

- Charlie

On Fri, Apr 10, 2009 at 10:15 PM, Charlie Moad <cwmoad@...149...> wrote:

I found that thread not too long ago and dug up the tool John mentioned.

http://www.dependencywalker.com/

Looks like our friend "msvcrXX" (msvcr90 for py2.6) is back. I am
removing the link from distutils right now and giving it a try.

- Charlie

On Fri, Apr 10, 2009 at 10:08 PM, Andrew Straw <strawman@...36...> wrote:

Charlie Moad wrote:

I am running into an error when importing matplotlib though. I'll
poke around but would appreciate extra eyes.

ImportError: DLL load failed: The specified procedure could not be found.

Hi Charlie, we've been batting this one around on MPL-users for a little
while... still no resolution though. See the thread started by Lorenzo
Di Gregorio "matplotlib._path failed on windows build for Python 2.6".

-Andrew

_Charlie_Moad · April 13, 2009, 3:20am

I updated the binaries at the same link as before:
http://drop.io/tvuqe3o

NOTE: I used John's OSX build scripts which ran great, but I am
getting a segfault when trying to plot. I need to call it a night and
might not have time to look into the issue this week. Please run with
my files and feel free to post for a release if the source and windows
files work.

- Charlie

···

On Fri, Apr 10, 2009 at 10:36 PM, Charlie Moad <cwmoad@...149...> wrote:

http://drop.io/tvuqe3o

Please test these windows builds. I committed a change to set
tcltk8.5 flags for python 2.6 and I also uploaded a modified
win32_static.zip file. Could someone please replace the previous one
with the newer version? It includes the tcltk8.5 headers needed for
the build. If these builds test out well I'll proceed with the whole
slew of files for the release later this weekend.

- Charlie

On Fri, Apr 10, 2009 at 10:20 PM, Charlie Moad <cwmoad@...149...> wrote:

Yeah, that worked. Removed the link from
distutils/cygwinccompiler.py. I didn't get the error from python 2.4
or 2.5, but that's probably because I have had them installed for a
while and these dll's have been installed from other modules. I'll
try to get some binaries posted soon.

- Charlie

On Fri, Apr 10, 2009 at 10:15 PM, Charlie Moad <cwmoad@...149...> wrote:

I found that thread not too long ago and dug up the tool John mentioned.

http://www.dependencywalker.com/

Looks like our friend "msvcrXX" (msvcr90 for py2.6) is back. I am
removing the link from distutils right now and giving it a try.

- Charlie

On Fri, Apr 10, 2009 at 10:08 PM, Andrew Straw <strawman@...36...> wrote:

Charlie Moad wrote:

I am running into an error when importing matplotlib though. I'll
poke around but would appreciate extra eyes.

ImportError: DLL load failed: The specified procedure could not be found.

Hi Charlie, we've been batting this one around on MPL-users for a little
while... still no resolution though. See the thread started by Lorenzo
Di Gregorio "matplotlib._path failed on windows build for Python 2.6".

-Andrew