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. > 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. Eric > 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
