> Yes, it seems that the v1.0.x got hosed somehow back in early
> Firing did some spelunking and traced it to a push I made, but
> sure what I did wrong, and I'm even less sure how to fix it. If
> with more git-fu wants to investigate and repair it, that would be
> fantastic, but I'm afraid to touch it myself.
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
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.
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.
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.)
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.
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.
continue to support (::cough:: Cairo ::cough::).
And emf, and plain wx, and plain gtk, and fltkagg. (Many months ago I posted a query to matplotlib-users as to whether anyone was actually *using* fltkagg; there was no reply. Regarding Cairo: I don't know what its status is, but it always seemed like a potentially useful backup in case of an Agg meltdown.) 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) in case someone eventually picks it up and pumps some life back into it. 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.
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.
On 06/01/2011 09:07 AM, Benjamin Root wrote:
On Wed, Jun 1, 2011 at 1:47 PM, Eric Firing <efiring@…229… > <mailto:efiring@…229…>> wrote:
On 06/01/2011 08:26 AM, Michael Droettboom wrote: