On Wed, Jun 1, 2011 at 2:58 PM, Eric Firing <efir...@hawaii.edu> wrote:
> On 06/01/2011 09:07 AM, Benjamin Root wrote:
> >
> >
> > On Wed, Jun 1, 2011 at 1:47 PM, Eric Firing <efir...@hawaii.edu
> > <mailto: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,
>
> Are you referring to animations.py? The last change in that file on
> master was 9 months ago.
>
>
Yeah... I guess we really haven't exercised it. However, I know some of my
existing animation code based on it is broken and I have spotted a few
potential issues in parts of the code. However, Ryan May is currently on
the finishing end of his Dissertation work (while I am only at the start of
it), and I doubt we will get much more out of him for a few more months.
>
> > 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.
> >
>
> Do the packagers use the tip of the maintenance branch, or do they use
> the most recent release? If the former, then that bumps up the priority
> of keeping such a branch. If the latter, it bumps up the priority of
> having frequent high-quality releases, regardless of what they are called.
>
>
>
I think that is dependent upon the repo. It seems that Ubuntu tends to stay
near the release, while I have seen some other repos stay very up to date (I
forget which one I saw). However, many of the changes we make are bugfixes
and then transition to feature changes.
> > The current practice worked very nicely with SVN (IMHO), and I think it
>
> (I recall that Mike had to rescue us more than once from svnmerge
> confusions, at least during the earlier days.)
>
>
So, it appears we have difficulties with new technologies?
> > 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
>
> I don't see the contradiction or inconsistency. I am not saying we
> *can't* keep a maintenance branch; I am saying it is not clear to me
> that it is worth the fuss to do so indefinitely, especially when it is
> infrequently released.
>
>
Well, I never really saw it as indefinite. I thought it was defined as
maintaining the current release. So, whenever we release v1.1.0, then we no
longer work on v1.0.x and bugfixes go to v1.1.x branch. Seems pretty clear
to me. So long as there is no snafus with the maintenance branch, then we
should be fine with this procedure.
> > 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
>
> So, all progress should be held hostage? This might work if we were a
> company, and could assign a programmer to a task. Given that we rely on
> volunteers, I don't think it is practical.
>
>
The bug fixes are still getting pushed out, and the next releases of the
distros will have updated versions. I don't want to put out half-working
features that ultimately gets rejected by users because it wasn't ready for
primetime. However, I do see your point and I think this is even more
evidence for a release manager. And to answer the next question -- no, I
simply will not have the time to do take that role (I am trying to get my
contributions done now before I go into hermit mode again).
But that would be a big change in mpl de facto
> policy, which has always been very liberal with respect to leaving
> decaying code in place (like mplot3d)
Hey!
> in case someone eventually picks
> it up and pumps some life back into it.
Ah, ok, nevermind...
> I have mixed thoughts about
> that; my general instinct would be to rip out such things, but John's
> liberal approach has actually worked quite well.
>
I don't like cruft either, but what I really don't like is redundant cruft.
For example, if tight_layout turns out to be useful, then I think that the
mplsizer module should probably go.
> >
> > But that's just my opinion.
> >
> It's good to get some opinions aired, to see if we can figure out ways
> to improve mpl and its development process.
>
>
That's my hope too.
Ben
------------------------------------------------------------------------------
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
