Re: [matplotlib-devel] Building documentation and matplotlibrc

2011-01-12 Thread Benjamin Root 
On Tue, Jan 11, 2011 at 3:13 PM, John Hunter  wrote:

> On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root  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
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Building documentation and matplotlibrc

2011-01-12 Thread Eric Firing 
On 01/12/2011 07:20 AM, Benjamin Root wrote:
> On Tue, Jan 11, 2011 at 3:13 PM, John Hunter  > wrote:
>
> On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root  > 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

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Building documentation and matplotlibrc

2011-01-12 Thread Sandro Tosi 
On Wed, Jan 12, 2011 at 18:20, Benjamin Root  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

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Building documentation and matplotlibrc

2011-01-12 Thread John Hunter 
On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi  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.

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Python-modules-team] Bug#608939: python-matplotlib-doc: minor glitch in draw_markers() description

2011-01-12 Thread Sandro Tosi 
forwarded 608939 matplotlib-devel@lists.sourceforge.net
thanks

Hello MPL Devs,

On Tue, Jan 4, 2011 at 20:13, Jakub Wilk  wrote:
> Package: python-matplotlib-doc
> Version: 0.99.3-1
> Severity: glitch
> User: python-modules-t...@lists.alioth.debian.org
> 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

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Python-modules-team] Bug#608939: Bug#608939: python-matplotlib-doc: minor glitch in draw_markers() description

2011-01-12 Thread Sandro Tosi 
On Wed, Jan 12, 2011 at 23:59, Sandro Tosi  wrote:
> Hello MPL Devs,
>
> On Tue, Jan 4, 2011 at 20:13, Jakub Wilk  wrote:
>> Package: python-matplotlib-doc
>> Version: 0.99.3-1
>> Severity: glitch
>> User: python-modules-t...@lists.alioth.debian.org
>> 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.

Now with attachment :)

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


matplotlib-doc-api-api_changes-draw_markers.diff
Description: application/mbox
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Building documentation and matplotlibrc

2011-01-12 Thread Benjamin Root 
On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi  wrote:

> On Wed, Jan 12, 2011 at 18:20, Benjamin Root  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,
>

I believe we are actually in agreement, but perhaps I wasn't clear enough.
The maintenance patches that I speak of are committed in the v1_0_maint
branch of the svn repo.  The tarball still has the original code from the
release point regardless of what patches have been committed since then.

Package maintainers can choose to cherry-pick those patches or even track
that maintenance branch for their own packaging purposes.  The point is that
new features should not be added (unless absolutely necessary) and that old
features are not removed on that branch.

Please see our coding guide under "Committing Changes" (particularly the
last bullet):

> Keep the maintenance branch (0.91) the latest release branch (eg 0.98.4)
> and trunk in sync where it makes sense. If there is a bug on both that needs
> fixing, use svnmerge.py  to
> keep them in sync.
>

So, back to the issue regarding whether to put out a 1.0.2 or not.  We will
always be wanting to patch things (lord knows there are enough bugs...) and
at some point we have to say "it is good enough".  Right now, my only major
qualm with the current 1.0.1 release has been the documentation (by the way,
the Coding Guide page looks terrible on my small screen).  Code-wise, I am
willing to accept it as is and start focusing on 1.1.0.

Ben Root
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Building documentation and matplotlibrc

2011-01-12 Thread Benjamin Root 
On Wed, Jan 12, 2011 at 12:56 PM, Eric Firing  wrote:

> On 01/12/2011 07:20 AM, Benjamin Root wrote:
> > On Tue, Jan 11, 2011 at 3:13 PM, John Hunter  > > wrote:
> >
> > On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root  > > 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
>
>
I agree, I think that is the direction MPL needs to go.  We are
feature-packed, but still have a lot of rough edges.  The prospect of being
a release manager is great, but it will depend on when we plan to release if
I will have enough time to devote to that.

Ben Root
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Missing ct.raw from sampledata tarball

2011-01-12 Thread Sandro Tosi 
Hi!
There is an example using ct.raw but it's not included in the
'sourcedata' tarball:

/home/morph/deb/build-area/matplotlib-1.0.1/build/lib.linux-x86_64-2.6/matplotlib/sphinxext/plot_directive.py:322:
PlotWarning: Exception running plot
/home/morph/deb/build-area/matplotlib-1.0.1/doc/mpl_examples/pylab_examples/image_demo2.py
Traceback (most recent call last):
  File 
"/home/morph/deb/build-area/matplotlib-1.0.1/build/lib.linux-x86_64-2.6/matplotlib/sphinxext/plot_directive.py",
line 319, in render_figures
run_code(plot_path, function_name, plot_code, context=context)
  File 
"/home/morph/deb/build-area/matplotlib-1.0.1/build/lib.linux-x86_64-2.6/matplotlib/sphinxext/plot_directive.py",
line 230, in run_code
"__plot__", fd, fname, ('py', 'r', imp.PY_SOURCE))
  File "image_demo2.py", line 9, in 
IOError: [Errno 2] No such file or directory:
'/home/morph/deb/build-area/matplotlib-1.0.1/sampledata/ct.raw'

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

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel