propose 1.1.0 release tomorrow

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

···

On Mon, Oct 3, 2011 at 7:54 AM, John Hunter <jdh2358@…149…> 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

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](https://github.com/matplotlib/matplotlib/pull/505)
      ("Geo divide

      zero") which I believe is ready to go.

      [https://github.com/matplotlib/matplotlib/pull/496](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
···

On 10/03/2011 01:01 PM, Benjamin Root wrote:

    On Mon, Oct 3, 2011 at 7:54 AM, John > Hunter <jdh2358@...149...> >         wrote:

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

···

On Mon, Oct 3, 2011 at 12:06 PM, Michael Droettboom <mdroe@...31...> 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)?"

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

···

On Mon, Oct 3, 2011 at 12:06 PM, Michael Droettboom <mdroe@…31…> wrote:

On 10/03/2011 01:01 PM, Benjamin Root wrote:

    On Mon, Oct 3, 2011 at 7:54 AM, John > > Hunter <jdh2358@...149...> > >         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.

nope, sadly that doesn't help.

Regards,

···

On Mon, Oct 3, 2011 at 23:00, Benjamin Root <ben.root@...553...> 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?

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

···

On Mon, Oct 3, 2011 at 5:31 PM, Sandro Tosi <morph@…12…> wrote:

On Mon, Oct 3, 2011 at 23:00, Benjamin Root <ben.root@…553…> 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

Hi Ben,
thanks for your support on this

log (196 KB)

···

On Tue, Oct 4, 2011 at 00:50, Benjamin Root <ben.root@...553...> wrote:

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.

Here attached the log (at the start of "writing output" I've Ctrl+c).

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

I’m looking into this. It seems there’s a pretty
straightforward-to-fix bug parsing the commandline arguments.
Beyond that, though, there appears to be a pretty serious (and
relatively recent) memory leak in the plot directive that’s
preventing my own runs from finishing. I will let you know when I
have some changes to try.

Mike
···

<ben.root@…553…>http://p.sf.net/sfu/splunk-d2dcopy1


Matplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

It seems the memory leak was due to a problem in Numpy git master
(I’ve yet to track down the root cause). Reverting to Numpy 1.6.1
resolves the issue, though.

As for your bug, it seems there is a bug in how the plot_formats

commandline argument is parsed. Could you please try this branch
and let me know if it resolves the issue?

Mike
···

https://github.com/mdboom/matplotlib/tree/doc_build_fail

  I'm looking into this.  It seems there's a pretty

straightforward-to-fix bug parsing the commandline arguments.
Beyond that, though, there appears to be a pretty serious (and
relatively recent) memory leak in the plot directive that’s
preventing my own runs from finishing. I will let you know when I
have some changes to try.

  Mike



  On 10/04/2011 02:35 AM, Sandro Tosi wrote:

Hi Ben,
thanks for your support on this
On Tue, Oct 4, 2011 at 00:50, Benjamin Root wrote:
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.

Here attached the log (at the start of "writing output" I've Ctrl+c).
HTH,


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.


Matplotlib-devel mailing list


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.


Matplotlib-devel mailing list

-- Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

<ben.root@…553…>http://p.sf.net/sfu/splunk-d2dcopy1


Matplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

http://p.sf.net/sfu/splunk-d2dcopy1


Matplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Nope, sadly I can still replicate it. Anyhow, I don't know how you
want to consider this blocking or not, I can live with the map()
instead of pool.map() as Ben suggested.

Cheers,

···

On Tue, Oct 4, 2011 at 20:00, Michael Droettboom <mdroe@...31...> wrote:

As for your bug, it seems there is a bug in how the plot_formats commandline
argument is parsed. Could you please try this branch and let me know if it
resolves the issue?

https://github.com/mdboom/matplotlib/tree/doc_build_fail

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

I think we should probably take the multiprocessing out -- it's only purpose is to increase the speed of the build, but if it fails in some circumstances, it's not worth saving a few seconds. I'd still like to address this properly in the future, so I'll file a bug.

Mike

···

On 10/05/2011 03:38 AM, Sandro Tosi wrote:

On Tue, Oct 4, 2011 at 20:00, Michael Droettboom<mdroe@...31...> wrote:

As for your bug, it seems there is a bug in how the plot_formats commandline
argument is parsed. Could you please try this branch and let me know if it
resolves the issue?

https://github.com/mdboom/matplotlib/tree/doc_build_fail

Nope, sadly I can still replicate it. Anyhow, I don't know how you
want to consider this blocking or not, I can live with the map()
instead of pool.map() as Ben suggested.

John,

Sorry to be holding things up after having nagged about getting a release out, but I just now marked #506 "release_critical". It looks like a pretty fundamental bug in blitting on qt4agg, and I think I introduced it back in January, right after 1.0.1. I can look more closely this evening; I am hoping it will be fairly simple and safe to fix.

Eric

···

On 10/03/2011 02: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.

Is this the issue Michael identified in this thread above pointing to:
"[matplotlib-devel] Typo in backend_qt4.py
(matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was
holding on that issue until I heard from him.

JDH

···

On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing <efiring@...229...> wrote:

Sorry to be holding things up after having nagged about getting a
release out, but I just now marked #506 "release_critical". It looks
like a pretty fundamental bug in blitting on qt4agg, and I think I
introduced it back in January, right after 1.0.1. I can look more
closely this evening; I am hoping it will be fairly simple and safe to fix.

On a separate note, I want to make sure I cut the rc1 correctly. The notes said to bump the version number in unit.py, but it was already at v1.1.0. Was I suppose to bump the version number from 1.1.0 in the master branch, or to v1.1.0 in the v1.1.x branch?

Right now, it is 1.1.0 in both branches.

Thanks,
Ben Root

···

On Wednesday, October 5, 2011, John Hunter <jdh2358@…149…> wrote:

On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing <efiring@…229…> wrote:

Sorry to be holding things up after having nagged about getting a
release out, but I just now marked #506 “release_critical”. It looks
like a pretty fundamental bug in blitting on qt4agg, and I think I

introduced it back in January, right after 1.0.1. I can look more
closely this evening; I am hoping it will be fairly simple and safe to fix.

Is this the issue Michael identified in this thread above pointing to:

“[matplotlib-devel] Typo in backend_qt4.py
(matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?” I was
holding on that issue until I heard from him.

JDH

John,

No, I had forgotten about that one--from that message it looks like there are two problems in backend_qt4 that are separate from the backend_qt4agg problem noted in #506. I am only trying to deal with the latter.

Eric

···

On 10/05/2011 11:17 AM, John Hunter wrote:

On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<efiring@...229...> wrote:

Sorry to be holding things up after having nagged about getting a
release out, but I just now marked #506 "release_critical". It looks
like a pretty fundamental bug in blitting on qt4agg, and I think I
introduced it back in January, right after 1.0.1. I can look more
closely this evening; I am hoping it will be fairly simple and safe to fix.

Is this the issue Michael identified in this thread above pointing to:
"[matplotlib-devel] Typo in backend_qt4.py
(matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was
holding on that issue until I heard from him.

JDH

#508 solves #506

The backend_qt4.py problem--the line property editor is broken--remains.

Eric

···

On 10/05/2011 11:17 AM, John Hunter wrote:

On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<efiring@...229...> wrote:

Sorry to be holding things up after having nagged about getting a
release out, but I just now marked #506 "release_critical". It looks
like a pretty fundamental bug in blitting on qt4agg, and I think I
introduced it back in January, right after 1.0.1. I can look more
closely this evening; I am hoping it will be fairly simple and safe to fix.

Is this the issue Michael identified in this thread above pointing to:
"[matplotlib-devel] Typo in backend_qt4.py
(matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was
holding on that issue until I heard from him.

JDH

I'm just getting to look at this now -- I'll report back once I have a sense of what the issues are.

Mike

···

On 10/05/2011 05:17 PM, John Hunter wrote:

On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<efiring@...229...> wrote:

Sorry to be holding things up after having nagged about getting a
release out, but I just now marked #506 "release_critical". It looks
like a pretty fundamental bug in blitting on qt4agg, and I think I
introduced it back in January, right after 1.0.1. I can look more
closely this evening; I am hoping it will be fairly simple and safe to fix.

Is this the issue Michael identified in this thread above pointing to:
"[matplotlib-devel] Typo in backend_qt4.py
(matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was
holding on that issue until I heard from him.

Pretty simple. I have a pull request here:

https://github.com/matplotlib/matplotlib/pull/509

Mike

···

On 10/06/2011 09:33 AM, Michael Droettboom wrote:

On 10/05/2011 05:17 PM, John Hunter wrote:

On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<efiring@...229...> wrote:

Sorry to be holding things up after having nagged about getting a
release out, but I just now marked #506 "release_critical". It looks
like a pretty fundamental bug in blitting on qt4agg, and I think I
introduced it back in January, right after 1.0.1. I can look more
closely this evening; I am hoping it will be fairly simple and safe to fix.

Is this the issue Michael identified in this thread above pointing to:
"[matplotlib-devel] Typo in backend_qt4.py
(matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was
holding on that issue until I heard from him.

I'm just getting to look at this now -- I'll report back once I have a
sense of what the issues are.

I confirmed the qt bugs Eric and Michael were working on and tested
the fixes, so i merged and closed these two. The only remaining issue
I am aware of is Sandro's map issue, and he said earlier in this
thread that he can use the map function rather than the pool, so I
think we are good to go today. Speak now if I am missing something!

···

On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom <mdroe@...31...> wrote:

Pretty simple. I have a pull request here:

https://github.com/matplotlib/matplotlib/pull/509