Thread: [matplotlib-devel] release strategy, and the role of v0_98_5_maint

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

On Sun, Apr 5, 2009 at 6:38 PM, Eric Firing <ef...@ha...> wrote:
> 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

JDH

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.

On Tue, Apr 7, 2009 at 18:06, Andrew Straw <str...@as...> 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

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 <mo...@de...> wrote:
> On Tue, Apr 7, 2009 at 18:06, Andrew Straw <str...@as...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I'd actually prefer it ;>

On Wed, Apr 8, 2009 at 9:14 AM, Charlie Moad <cw...@gm...> 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 <mo...@de...> wrote:
> > On Tue, Apr 7, 2009 at 18:06, Andrew Straw <str...@as...> 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
> > Mat...@li...
> > 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Apr 8, 2009, at 9:14 AM, Charlie Moad <cw...@gm...> 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

None here.

Thanks,
JDH



>
> - Charlie
>
> On Tue, Apr 7, 2009 at 5:02 PM, Sandro Tosi <mo...@de...> wrote:
>> On Tue, Apr 7, 2009 at 18:06, Andrew Straw <str...@as...>  
>> 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
>>
>> ------------------------------------------------------
>>

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

0.98.6 only?

On Wed, Apr 8, 2009 at 2:59 PM, Eric Firing <ef...@ha...> 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
>

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 <cw...@gm...> wrote:
> 0.98.6 only?
>
> On Wed, Apr 8, 2009 at 2:59 PM, Eric Firing <ef...@ha...> 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
>>
>

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 <cw...@gm...> wrote:
>   
>> 0.98.6 only?
>>
>> On Wed, Apr 8, 2009 at 2:59 PM, Eric Firing <ef...@ha...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

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

On Apr 10, 2009 2:06pm, Charlie Moad <cw...@gm...> 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

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

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 <str...@as...> 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
>

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 <cw...@gm...> 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 <str...@as...> 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
>>
>

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 <cw...@gm...> 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 <cw...@gm...> 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 <str...@as...> 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
>>>
>>
>

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 <cw...@gm...> 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 <cw...@gm...> 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 <cw...@gm...> 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 <str...@as...> 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
>>>>
>>>
>>
>

On Sun, Apr 12, 2009 at 10:20 PM, Charlie Moad <cw...@gm...> wrote:
> I updated the binaries at the same link as before:
> http://drop.io/tvuqe3o

I just tested the python2.5 installer
matplotlib-0.98.5.3.win32-py2.5.exe and get a segfault when I try and
import matplotlib.backends._tkagg

When I open _tkagg.pyd in dependencywalker, it appears to be missing
"DWMAPI.DLL".  Any ideas?

JDH

On Mon, Apr 13, 2009 at 11:46 AM, John Hunter <jd...@gm...> wrote:
> On Sun, Apr 12, 2009 at 10:20 PM, Charlie Moad <cw...@gm...> wrote:
>> I updated the binaries at the same link as before:
>> http://drop.io/tvuqe3o
>
> I just tested the python2.5 installer
> matplotlib-0.98.5.3.win32-py2.5.exe and get a segfault when I try and
> import matplotlib.backends._tkagg
>
> When I open _tkagg.pyd in dependencywalker, it appears to be missing
> "DWMAPI.DLL".  Any ideas?

Looks like it's a MingW issue.

http://bugs.python.org/issue3308

Unfortunately I am at a conference until the weekend.  Any results
from the osx binaries?

- Charlie

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

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,  <jd...@gm...> wrote:
> On Apr 10, 2009 2:06pm, Charlie Moad <cw...@gm...> 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

>> 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.