On Wed, Jun 1, 2011 at 1:47 PM, Eric Firing <efir...@hawaii.edu> wrote:
> On 06/01/2011 08:26 AM, Michael Droettboom wrote:
> > Yes, it seems that the v1.0.x got hosed somehow back in early May. Eric
> > Firing did some spelunking and traced it to a push I made, but I'm not
> > sure what I did wrong, and I'm even less sure how to fix it. If someone
> > with more git-fu wants to investigate and repair it, that would be
> > fantastic, but I'm afraid to touch it myself.
> >
> > Mike
>
> Mike, all:
>
> Suggestion: Let's just abandon the v1.0.x branch, stabilize master, and
> get a release out. (Easy for me to say--I have never contributed to the
> actual release process.) I think that we really need to get releases
> out more frequently--that needs to become a higher priority. I don't
> think it is even worth the trouble to maintain a maintenance branch at
> all. It adds quite a bit of complexity to the development and release
> process--every time a bug is found, the fix has to be developed on
> maintenance, committed and pushed, checked on master, and propagated to
> master. It's not worth it. The differences between master and
> maintenance are normally not large enough to justify keeping them
> separate, given our very constrained people-time resources.
>
> Note that a release doesn't have to be made from master HEAD; git
> branching is extremely flexible, so at any time, one can make a branch
> from any point on the tree, do some checking and adjustment, and release
> it. Where we get into difficulty and waste time is in trying to
> maintain a separate maintenance branch for a long period. We just don't
> have the resources to do this well; and we don't really need to do it at
> all.
>
> Eric
>
>
Actually, there are plenty of differences between v1.0.x and master. We
have a number of new features that are baking right now (animations, for
example). I have personally made a number of changes with mplot3d that, in
some cases, were too risky to apply to v1.0.x and I just wanted them to sit
in the official development branch rather than in the stable branch. Also,
because there is not much of downstream activity to the repos, I think many
of the packagers depend upon the bugfixes we apply to the maintenance
branches. I am hesitant to change development policies without a clear
consideration for downstream.
The current practice worked very nicely with SVN (IMHO), and I think it
still works fine. Most of the issues is really limited to svn --> git
transitions and understanding how git works. I will agree that it is
possible that the v1.0.x branch might be damaged beyond repair. I am not
enough of a git expert to know one way or another.
As for the comment about getting releases out faster, this contradicts your
assertion that we don't have the manpower to take care of the maintenance
branch. We do need better planning for milestones and goals, but I don't
want to push out a release until it is ready. In particular, I think a good
rule of thumb for the v1.1.0 release should be to have *all* the backends
behaving the same (::cough:: macosx ::cough::), and to officially deprecate
any backends that we can not continue to support (::cough:: Cairo
::cough::).
But that's just my opinion.
Ben Root
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
