On Wed, Jan 12, 2011 at 12:56 PM, Eric Firing <efir...@hawaii.edu> wrote:
> On 01/12/2011 07:20 AM, Benjamin Root wrote:
> > On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jdh2...@gmail.com
> > <mailto:jdh2...@gmail.com>> wrote:
> >
> > On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben.r...@ou.edu
> > <mailto:ben.r...@ou.edu>> 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
