matplotlib-devel Mailing List for matplotlib

forwarded 608939 mat...@li...
thanks

Hello MPL Devs,

On Tue, Jan 4, 2011 at 20:13, Jakub Wilk <jw...@de...> wrote:
> Package: python-matplotlib-doc
> Version: 0.99.3-1
> Severity: glitch
> User: pyt...@li...
> Usertags: sphinx1.0
> Tags: patch
>
> See the attached patch.

Jakub wrote a patch that fix the link from draw_markers() in
api_change to its documentation. It's exploited when using sphinx1.x,
I'm forwarding the patch to let it be applied upstream.

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

On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi <mo...@de...> wrote:

> If you're saying you want to publish another tarball with version
> 1.0.1 that has different contents of the current one, than with my
> distro package maintainer and programmer hats on I say "you should
> not". If you have published (and not advertised, ok) something, you
> cannot re-publish the same version but with something "different" in
> it. Just go with 1.0.2, distros have (usually) the latest version and
> you are free to release patches in the HEAD of your development tree:
> it's a distro package maintainer evaluate if this patches are to be
> backported to the distro version, if the version cannot be bring
> up-to-date with the latest release.

Exactly, once we upload a version with a number, it is fixed.  It
becomes really difficult to debug when two people think they are using
the same code and looking at different bases.

On Wed, Jan 12, 2011 at 18:20, Benjamin Root <ben...@ou...> wrote:
> I am fine with letting 1.0.1 go out as is (unless we can't live with the

is already out: look at SF download page to see how many have downloaded it.

> documentation typos that has shown up).  I am also hesistant about putting
> out yet another bug-fix release because there will be distros that will have
> 1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into a
> maintenance nightmare.  Instead, let's just let those package maintainers
> keep up with the patches to 1.0.1.
>
> This also raises a question.  When putting out maintenance patches, are we
> going to have to patch 1.0.0 and 1.0.1?

If you're saying you want to publish another tarball with version
1.0.1 that has different contents of the current one, than with my
distro package maintainer and programmer hats on I say "you should
not". If you have published (and not advertised, ok) something, you
cannot re-publish the same version but with something "different" in
it. Just go with 1.0.2, distros have (usually) the latest version and
you are free to release patches in the HEAD of your development tree:
it's a distro package maintainer evaluate if this patches are to be
backported to the distro version, if the version cannot be bring
up-to-date with the latest release.

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

On 01/12/2011 07:20 AM, Benjamin Root wrote:
> On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jd...@gm...
> <mailto:jd...@gm...>> wrote:
>
>     On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou...
>     <mailto:ben...@ou...>> wrote:
>      > John,
>      >
>      > Just to clarify, have we officially released 1.0.1, or are we
>     still in the
>      > RC phase?  If we haven't released yet, what is the deadline for final
>      > patches for 1.0.1?
>      >
>
>     1.0.1 is final but I held off on the announcement until Russel got the
>     OSX builds uploaded (which he did yesterday, but I still haven't
>     gotten to the announcement).  If there are significant problems (eg
>     the 3D stuff you reported or other issues) I have no problem pushing
>     out 1.0.2 quickly.
>
>     JDH
>
>
> John,
>
> I am fine with letting 1.0.1 go out as is (unless we can't live with the
> documentation typos that has shown up).  I am also hesistant about
> putting out yet another bug-fix release because there will be distros
> that will have 1.0.0, 1.0.1, and then possibly others with 1.0.2, which
> would turn into a maintenance nightmare.  Instead, let's just let those
> package maintainers keep up with the patches to 1.0.1.
>
> This also raises a question.  When putting out maintenance patches, are
> we going to have to patch 1.0.0 and 1.0.1?
>
> I think what happened with 1.0.1 is that while there were some clear
> goals (solidification of the backend codes and getting the no-download
> doc feature working), it also became a bit of a free-for-all for
> receiving other patches (I am guilty of this).  Personally, I lost sight
> of the point of the RCs and that is to seek out and squash only the
> show-stopper bugs.  Any other patches should not go in.
>
> Looking forward, I think there are a couple of things that we can do for
> the next release (1.1.0?) that would be greatly beneficial.  First, I
> think having a clear and firm (but not set-in-stone) release date is
> important.  Second, release candidates should probably be made available
> for a couple of weeks.  Third, I think when it comes time for a release,
> there should be at least one or two other developers agreeing on the
> release (the purpose of this is to give a last-chance for any
> objections, and to share the responsibility of the release).  Last,
> there should probably be clearer goals/milestones for the releases.
>
> I would appreciate any thoughts/comments on this.  We can start up a new
> thread if it is more appropriate.
>
> Ben Root
>

Ben,

It sounds like what you are talking about is more like the way numpy has 
been working, complete with a release manager.  Would you be willing and 
able to take on that role, along with all the other excellent work you 
have been doing?  It would be a big step forward for mpl, I think.

Eric

On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jd...@gm...> wrote:

> On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou...> wrote:
> > John,
> >
> > Just to clarify, have we officially released 1.0.1, or are we still in
> the
> > RC phase?  If we haven't released yet, what is the deadline for final
> > patches for 1.0.1?
> >
>
> 1.0.1 is final but I held off on the announcement until Russel got the
> OSX builds uploaded (which he did yesterday, but I still haven't
> gotten to the announcement).  If there are significant problems (eg
> the 3D stuff you reported or other issues) I have no problem pushing
> out 1.0.2 quickly.
>
> JDH
>

John,

I am fine with letting 1.0.1 go out as is (unless we can't live with the
documentation typos that has shown up).  I am also hesistant about putting
out yet another bug-fix release because there will be distros that will have
1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into a
maintenance nightmare.  Instead, let's just let those package maintainers
keep up with the patches to 1.0.1.

This also raises a question.  When putting out maintenance patches, are we
going to have to patch 1.0.0 and 1.0.1?

I think what happened with 1.0.1 is that while there were some clear goals
(solidification of the backend codes and getting the no-download doc feature
working), it also became a bit of a free-for-all for receiving other patches
(I am guilty of this).  Personally, I lost sight of the point of the RCs and
that is to seek out and squash only the show-stopper bugs.  Any other
patches should not go in.

Looking forward, I think there are a couple of things that we can do for the
next release (1.1.0?) that would be greatly beneficial.  First, I think
having a clear and firm (but not set-in-stone) release date is important.
Second, release candidates should probably be made available for a couple of
weeks.  Third, I think when it comes time for a release, there should be at
least one or two other developers agreeing on the release (the purpose of
this is to give a last-chance for any objections, and to share the
responsibility of the release).  Last, there should probably be clearer
goals/milestones for the releases.

I would appreciate any thoughts/comments on this.  We can start up a new
thread if it is more appropriate.

Ben Root

Benjamin Root, on 2011-01-11 14:55,  wrote:
> I am on the online version of the matplotlib documentation, and I am finding
> some artifacts of the Sphinx build.
> 
> For example there is ".. _gridspec-guide:" at the top of the page on
> http://matplotlib.sourceforge.net/users/gridspec.html

Hi Ben,

I sent a fix for the gridspec-guide anchor in a patch that
included a new gridspec example before I got commit rights, but
Jae-Joon wanted to examine it further before committing. I just
checked in the trivial fix for this in r8903.

> There is also a " `AxesGrid`_" in the last paragraph of this section:
> http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#what-is-axesgrid-toolkit

using 

  svn log doc/mpl_toolkits/axes_grid/users/overview.rst

to track down when this file changed, I saw that r8010 

  svn diff -r 8010 doc/mpl_toolkits/axes_grid/users/overview.rst

made a few changes of the instance AxesGrid to ImageGrid,
including a section title that went from being "Axes Grid" to
"Image Grid", so that's probably how the broken link happened.

I took care of it in r8094 just now.

Also, to preempt potential race condition on improving the docs -
I have a substantial fix-up of a bunch of typos in the docstrings
of mpl_toolkits/axes_grid1/ files that I'll check in later on
tonight or tomorrow.

best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7