[matplotlib-devel] propose 1.1.0 release tomorrow

2011-10-03 Thread John Hunter 
We made some additional progress over the weekend closing pull
requests and issues, and I think we are ready to release tomorrow if
no one objects.  I want to hold off for a day to give people who do
most of their work during the week a chance to close/finish/polish any
lingering issues.

The only open pull request that should be closed ahead of the release
is https://github.com/matplotlib/matplotlib/pull/505 ("Geo divide
zero") which I believe is ready to go.
https://github.com/matplotlib/matplotlib/pull/496 ("Added Carey
Rappaport's CMRmap colour map") ooks harmless and if someone wants to
merge it into v1.1.x rather than master (as the request states) I see
no reason not to.  On the issue list, nothing is tagged as release
critical.

Christoph had requested an upgrade of pytz ahead of the release, but I
am reluctant to make a big change at the final hour unless there are
some known, fairly serious bugs in the version we are shipping in
which case we can consider it release critical and hold for upgrade
and testing.

Once we cut the release, we'll want to merge all the changes into
master.  I discussed this with  Jouni over the weekend and we think
that the only thing that doesn't need to be merged is the __version__
string so it will probably be pretty simple, but if we are missing
something please speak up.

JDH

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

2011-10-03 Thread Benjamin Root 
On Mon, Oct 3, 2011 at 7:54 AM, John Hunter  wrote:

> We made some additional progress over the weekend closing pull
> requests and issues, and I think we are ready to release tomorrow if
> no one objects.  I want to hold off for a day to give people who do
> most of their work during the week a chance to close/finish/polish any
> lingering issues.
>
> The only open pull request that should be closed ahead of the release
> is https://github.com/matplotlib/matplotlib/pull/505 ("Geo divide
> zero") which I believe is ready to go.
> https://github.com/matplotlib/matplotlib/pull/496 ("Added Carey
> Rappaport's CMRmap colour map") ooks harmless and if someone wants to
> merge it into v1.1.x rather than master (as the request states) I see
> no reason not to.  On the issue list, nothing is tagged as release
> critical.
>
> Christoph had requested an upgrade of pytz ahead of the release, but I
> am reluctant to make a big change at the final hour unless there are
> some known, fairly serious bugs in the version we are shipping in
> which case we can consider it release critical and hold for upgrade
> and testing.
>
> Once we cut the release, we'll want to merge all the changes into
> master.  I discussed this with  Jouni over the weekend and we think
> that the only thing that doesn't need to be merged is the __version__
> string so it will probably be pretty simple, but if we are missing
> something please speak up.
>
> JDH
>
>
I am fine with that, so long as we have confirmed that there are no critical
issues with the Windows and Mac binaries.

I also remember Sandro having difficulties with building the docs for
Debian, but I haven't been able to replicate his problem.  It sounds like he
is having an exception being thrown and kicking him over to the pdb, but
with the multiprocessing feature we added, it just hangs because the pdb
can't connect to the terminal as a child process.  Maybe it would be useful
to have a switch to turn off multiprocessing for debugging purposes?

Ben Root
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

2011-10-03 Thread Michael Droettboom 

On 10/03/2011 01:01 PM, Benjamin Root wrote:
On Mon, Oct 3, 2011 at 7:54 AM, John Hunter > wrote:


We made some additional progress over the weekend closing pull
requests and issues, and I think we are ready to release tomorrow if
no one objects.  I want to hold off for a day to give people who do
most of their work during the week a chance to close/finish/polish any
lingering issues.

The only open pull request that should be closed ahead of the release
is https://github.com/matplotlib/matplotlib/pull/505 ("Geo divide
zero") which I believe is ready to go.
https://github.com/matplotlib/matplotlib/pull/496 ("Added Carey
Rappaport's CMRmap colour map") ooks harmless and if someone wants to
merge it into v1.1.x rather than master (as the request states) I see
no reason not to.  On the issue list, nothing is tagged as release
critical.

Christoph had requested an upgrade of pytz ahead of the release, but I
am reluctant to make a big change at the final hour unless there are
some known, fairly serious bugs in the version we are shipping in
which case we can consider it release critical and hold for upgrade
and testing.

Once we cut the release, we'll want to merge all the changes into
master.  I discussed this with  Jouni over the weekend and we think
that the only thing that doesn't need to be merged is the __version__
string so it will probably be pretty simple, but if we are missing
something please speak up.

JDH


I am fine with that, so long as we have confirmed that there are no 
critical issues with the Windows and Mac binaries.


I'm just getting back from vacation, so excuse me if I'm late to the 
party.  This sounds fine to me, but there was one pretty serious report 
about the Qt backend.  I haven't had a chance to investigate this yet, 
but will do so soon.  See the thread:


"[matplotlib-devel] Typo in backend_qt4.py
(matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?"




I also remember Sandro having difficulties with building the docs for 
Debian, but I haven't been able to replicate his problem.  It sounds 
like he is having an exception being thrown and kicking him over to 
the pdb, but with the multiprocessing feature we added, it just hangs 
because the pdb can't connect to the terminal as a child process.  
Maybe it would be useful to have a switch to turn off multiprocessing 
for debugging purposes?


That's probably a good idea.

Mike
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

2011-10-03 Thread John Hunter 
On Mon, Oct 3, 2011 at 12:06 PM, Michael Droettboom  wrote:

> I'm just getting back from vacation, so excuse me if I'm late to the party.
> This sounds fine to me, but there was one pretty serious report about the Qt
> backend.  I haven't had a chance to investigate this yet, but will do so
> soon.  See the thread:
>
> "[matplotlib-devel] Typo in backend_qt4.py
> (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?"

Since you were away, you may have missed the introduction of the tag
"release_critical".  As you are working through the issues, if you add
this tag to anything I'll hold off until they are cleared.

JDH

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

2011-10-03 Thread Benjamin Root 
On Mon, Oct 3, 2011 at 12:06 PM, Michael Droettboom  wrote:

> **
> On 10/03/2011 01:01 PM, Benjamin Root wrote:
>
> On Mon, Oct 3, 2011 at 7:54 AM, John Hunter  wrote:
>
>
> I also remember Sandro having difficulties with building the docs for
> Debian, but I haven't been able to replicate his problem.  It sounds like he
> is having an exception being thrown and kicking him over to the pdb, but
> with the multiprocessing feature we added, it just hangs because the pdb
> can't connect to the terminal as a child process.  Maybe it would be useful
> to have a switch to turn off multiprocessing for debugging purposes?
>
>
> That's probably a good idea.
>
>
Sandro,

I tried this once, but I don't remember if it worked or not.  In
doc/make.py, there is a os.system call to sphinx-build.  The "-P" option
apparently forces sphinx to kick over to the pdb upon an exception.  Try
removing that option and rebuild the docs again.  Maybe it won't hang
anymore?

Ben Root
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

2011-10-03 Thread Sandro Tosi 
On Mon, Oct 3, 2011 at 23:00, Benjamin Root  wrote:
> I tried this once, but I don't remember if it worked or not.  In
> doc/make.py, there is a os.system call to sphinx-build.  The "-P" option
> apparently forces sphinx to kick over to the pdb upon an exception.  Try
> removing that option and rebuild the docs again.  Maybe it won't hang
> anymore?

nope, sadly that doesn't help.

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

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] propose 1.1.0 release tomorrow

2011-10-03 Thread Benjamin Root 
On Mon, Oct 3, 2011 at 5:31 PM, Sandro Tosi  wrote:

> On Mon, Oct 3, 2011 at 23:00, Benjamin Root  wrote:
> > I tried this once, but I don't remember if it worked or not.  In
> > doc/make.py, there is a os.system call to sphinx-build.  The "-P" option
> > apparently forces sphinx to kick over to the pdb upon an exception.  Try
> > removing that option and rebuild the docs again.  Maybe it won't hang
> > anymore?
>
> nope, sadly that doesn't help.
>
> Regards,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>

Ok, then on line 112 of doc/sphinxext/gen_gallery.py, get rid of "pool." and
just do a regular map() call.  This will force single processing mode and
reveal which example is causing issues.

Ben Root
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel