Re: [matplotlib-devel] v1.0.x branch seems confused
Thu, 02 Jun 2011 17:48:55 -0400, Darren Dale wrote: [clip] > * "git reset --hard 0e6dad5230" > * redo pull request 103 > * cherry-pick the following commits off of the v1.0.x branch: > - 069c21d > - 53f8139e > - de18d9ab2 > - 91e7d980 > - 0cc213b4fa > - e7f1e83ace > - 5c968a0ecdd > > That should bring the v1.0.x-cleanup branch back to where we thought it > would be. I'll post the result in my fork as soon as it is ready, and > request comment. At that point, we should decide if we want to rename it > v1.0.x and force push, or rename it v1.0.x-maint (or whatever) and > delete the current v1.0.x branch. > > Pauli, Jouni, any comments? Seems OK to me. Pauli -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale wrote: > Before we made the git transition, I read about various workflows. > What we are doing now is somewhat similar to what used to be done with > svnmerge. I just googled "git workflow", and found > http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html . > See the section on "Merging Upwards": > > Responding to a few of the points mentioned above -- definitely +1 on more releases. I have been the bottleneck here and can do more. With that in mind, let's plan on getting a trunk release out with a 2 week timeline or so. I think there is a solid case for a release branch, so we can test/refine/fix while allowing development in the trunk. Once it is released, one suggestion is to can keep it around as maintenance but only for release critical bugs so that if we discover a show stopper three weeks after the release, we can cut a bugfix release w/ a shorted round of testing. Perhaps if we limit it to release critical bugs, this will lower the development burden on maintaining it and merging it. On the animations issue, I have noticed one strange behavior when I tried to remove the gtk extension code and replace it with pure python and found the new animations API behaved strangely (but not the old) under the new code. I never committed my changes because I could not resolve whether it was my code or Ryan's that was causing the problem, and he wasn't sure either. But incompletely baked features (and I wouldn't even call the animations code incompletely baked) are OK for releases. It's better to get them out there and in use so our users can find and fix the bugs :-) JDH -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
On Wed, Jun 1, 2011 at 2:58 PM, Eric Firing wrote: > 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. > > debian has been pretty clear that they want to build their packages from tarballs which we have uploaded and announced. JDH -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
On Fri, Jun 3, 2011 at 4:39 AM, John Hunter wrote: > On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale wrote: >> >> Before we made the git transition, I read about various workflows. >> What we are doing now is somewhat similar to what used to be done with >> svnmerge. I just googled "git workflow", and found >> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html . >> See the section on "Merging Upwards": >> > > Responding to a few of the points mentioned above -- definitely +1 on more > releases. I have been the bottleneck here and can do more. With that in > mind, let's plan on getting a trunk release out with a 2 week timeline or > so. That would be great. I am eager to merge the py3 stuff back into the main repository and start thinking about a 1.2 release. > I think there is a solid case for a release branch, so we can > test/refine/fix while allowing development in the trunk. Once it is > released, one suggestion is to can keep it around as maintenance but only > for release critical bugs so that if we discover a show stopper three weeks > after the release, we can cut a bugfix release w/ a shorted round of > testing. Perhaps if we limit it to release critical bugs, this will lower > the development burden on maintaining it and merging it. Sounds like a good idea. -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
On Fri, Jun 3, 2011 at 3:39 AM, John Hunter wrote: > On the animations issue, I have noticed one strange behavior when I tried to > remove the gtk extension code and replace it with pure python and found the > new animations API behaved strangely (but not the old) under the new code. > I never committed my changes because I could not resolve whether it was my > code or Ryan's that was causing the problem, and he wasn't sure either. But > incompletely baked features (and I wouldn't even call the animations code > incompletely baked) are OK for releases. It's better to get them out there > and in use so our users can find and fix the bugs :-) Well if you need to rip it out/"temporarily" break it to improve the gtk backend, by all means do so. I'll be bogged down for a few more months, after which I'll be able to work more on it. (FINALLY.) The only reason I even checked it in originally was so that others could play, but I was (and still am) not ready to commit completely to the API. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
Well if you need to rip it out/"temporarily" break it to improve the > gtk backend, by all means do so. I'll be bogged down for a few more > months, after which I'll be able to work more on it. (FINALLY.) The > only reason I even checked it in originally was so that others could > play, but I was (and still am) not ready to commit completely to the > API. > Not at all, I think it is at least as likely that there is a problem with my gtk code rather than a problem in the animations API. I only brought this up as an example of how I would rather release mostly functioning code with a few possible warts than incubate it in the trunk for months. What you have done is so much better than what we have that it needs to get out there even if we have to fix or change the API later. JDH -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
On Fri, Jun 3, 2011 at 8:50 AM, Ryan May wrote: > On Fri, Jun 3, 2011 at 3:39 AM, John Hunter wrote: > > On the animations issue, I have noticed one strange behavior when I tried > to > > remove the gtk extension code and replace it with pure python and found > the > > new animations API behaved strangely (but not the old) under the new > code. > > I never committed my changes because I could not resolve whether it was > my > > code or Ryan's that was causing the problem, and he wasn't sure either. > But > > incompletely baked features (and I wouldn't even call the animations code > > incompletely baked) are OK for releases. It's better to get them out > there > > and in use so our users can find and fix the bugs :-) > > Well if you need to rip it out/"temporarily" break it to improve the > gtk backend, by all means do so. I'll be bogged down for a few more > months, after which I'll be able to work more on it. (FINALLY.) The > only reason I even checked it in originally was so that others could > play, but I was (and still am) not ready to commit completely to the > API. > > Ryan > > The problem is that there aren't a lot of people playing with this code, and people are still using the documentation's examples for animations. Maybe we ought to consider a mechanism to release it with the next release with a huge "experimental" sticker on it, somehow? 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
On Fri, Jun 3, 2011 at 3:39 AM, John Hunter wrote: > On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale wrote: > >> Before we made the git transition, I read about various workflows. >> What we are doing now is somewhat similar to what used to be done with >> svnmerge. I just googled "git workflow", and found >> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html . >> See the section on "Merging Upwards": >> >> > Responding to a few of the points mentioned above -- definitely +1 on more > releases. I have been the bottleneck here and can do more. With that in > mind, let's plan on getting a trunk release out with a 2 week timeline or > so. > > I think there is a solid case for a release branch, so we can > test/refine/fix while allowing development in the trunk. Once it is > released, one suggestion is to can keep it around as maintenance but only > for release critical bugs so that if we discover a show stopper three weeks > after the release, we can cut a bugfix release w/ a shorted round of > testing. Perhaps if we limit it to release critical bugs, this will lower > the development burden on maintaining it and merging it. > Why not just call it a release candidate and follow a similar process for it as numpy just did a short while ago? Plus, with regards to timing. Do we want to release before or after the upcoming SciPy conference in July? Depending on who will be there (unfortunately, I won't be), we might want to wait for after that conference to take advantage of any activity then. Also, I know I have repeatedly stated that I won't be a release manager, but I am going to put together a wish-list of mine for what I would like to see for the next release. Maybe with that as a base, we can come up with a final set of goals for v1.1.0 and determine how much time it would take to get there? 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
On Fri, Jun 3, 2011 at 10:04 AM, Benjamin Root wrote: > On Fri, Jun 3, 2011 at 3:39 AM, John Hunter wrote: >> >> On Thu, Jun 2, 2011 at 9:06 PM, Darren Dale wrote: >>> >>> Before we made the git transition, I read about various workflows. >>> What we are doing now is somewhat similar to what used to be done with >>> svnmerge. I just googled "git workflow", and found >>> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html . >>> See the section on "Merging Upwards": >>> >> >> Responding to a few of the points mentioned above -- definitely +1 on >> more releases. I have been the bottleneck here and can do more. With that >> in mind, let's plan on getting a trunk release out with a 2 week timeline or >> so. >> >> I think there is a solid case for a release branch, so we can >> test/refine/fix while allowing development in the trunk. Once it is >> released, one suggestion is to can keep it around as maintenance but only >> for release critical bugs so that if we discover a show stopper three weeks >> after the release, we can cut a bugfix release w/ a shorted round of >> testing. Perhaps if we limit it to release critical bugs, this will lower >> the development burden on maintaining it and merging it. > > Why not just call it a release candidate and follow a similar process for it > as numpy just did a short while ago? > > Plus, with regards to timing. Do we want to release before or after the > upcoming SciPy conference in July? Depending on who will be there > (unfortunately, I won't be), we might want to wait for after that conference > to take advantage of any activity then. If we have the resources, it might be better to release before, and encourage activity at scipy to focus on py3 support (assuming it has been merged into master by then). -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x branch seems confused
On Fri, Jun 3, 2011 at 9:04 AM, Benjamin Root wrote: > > > Plus, with regards to timing. Do we want to release before or after the > upcoming SciPy conference in July? Depending on who will be there > (unfortunately, I won't be), we might want to wait for after that conference > to take advantage of any activity then. > > I don't feel the need to wait -- things move slowly enought that we might get one release out in the next couple of weeks and one bugfix release 2-4 weeks after that and that will dovetail with scipy conference. Also, my June is a lot better than my July as I will be traveling in July for the first couple of weeks. > Also, I know I have repeatedly stated that I won't be a release manager, > but I am going to put together a wish-list of mine for what I would like to > see for the next release. Maybe with that as a base, we can come up with a > final set of goals for v1.1.0 and determine how much time it would take to > get there? > This might be a better idea for a 1.2 release, since this sounds like it will take a while. There has been a lot of progress in the trunk since 1.0.1 and with the release-early-release-often philosophy I'd rather get something out there and then if we want to do something more formalized for the next iteration we will have plenty of time for it. I would shoot for people to get their changes in for a 1.1 release by early next week, branch and cut a release candidate, test for a week and put in bug fixes, cut a second release candidate a week later. If people would like more time for a formal process and bug closing extravaganza, I'm fine with that too. JDH -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x RIP, long live v1.0.x-maint
On Thu, Jun 2, 2011 at 6:46 PM, Darren Dale wrote: > Folks, > > We had some minor confusion with a merge a few weeks back, which > pulled much of the master branch into the v1.0.x maintenance branch. I > created a new v1.0.x-maint branch that rolled back all of the changes > from that point on, and cherry-picked all of the changes that were > actually intended for the v1.0.x branch. > > Please use v1.0.x-maint from now on. v1.0.x has been deleted from the > repository (though I'll keep a local copy for a few weeks as a backup, > just in case). > > If you have any changes that branched from v1.0.x after May 6 2011, > please contact me off list so we can correctly apply those changes on > top of v1.0.x-maint. > > Darren > > There might be a missing commit. I just noticed that a bunch of .py source files are missing in doc/mpl_toolkits/axes_grid/figures/. This might require cherry-picking a50874b711983cba505e which was the commit that Michael used to restore some of the mistakes of the commits on May 6th. I will leave it up to Darren to figure out exactly what would be the correct course of action. Ben Root P.S. : As an interesting aside to what caused me to find this mistake... My docs were still not building correctly, although now that the v1.0.x branch is fixed, it didn't have the multiprocessing trick that is in master. Therefore, when the error occurred, a message was able to be printed to my screen, which allows me to trace it down. What happens is that eventually, the python debugger is fired off by sphinx. If possible, it would probably be wise to disable this behavior as it makes no sense for doc-building. What triggers the startup of pdb is that the copying of simple_axes_divider2.py fails at line 403 of plot_directive.py, in _plot_directive(). This failure, however, is actually not the first error, as the first one gets swallowed by a try...finally statement at line 230, in run_code() of the same file. Because of the removal of the .py files as noted above, I only had .pyc files in that directory, which lead to the build system thinking that there was content to build. I see these assumptions as being problematic, and should probably be rethought in the future. -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x RIP, long live v1.0.x-maint
On Fri, Jun 3, 2011 at 1:21 PM, Benjamin Root wrote: > On Thu, Jun 2, 2011 at 6:46 PM, Darren Dale wrote: >> >> Folks, >> >> We had some minor confusion with a merge a few weeks back, which >> pulled much of the master branch into the v1.0.x maintenance branch. I >> created a new v1.0.x-maint branch that rolled back all of the changes >> from that point on, and cherry-picked all of the changes that were >> actually intended for the v1.0.x branch. >> >> Please use v1.0.x-maint from now on. v1.0.x has been deleted from the >> repository (though I'll keep a local copy for a few weeks as a backup, >> just in case). >> >> If you have any changes that branched from v1.0.x after May 6 2011, >> please contact me off list so we can correctly apply those changes on >> top of v1.0.x-maint. >> >> Darren >> > > There might be a missing commit. I just noticed that a bunch of .py source > files are missing in doc/mpl_toolkits/axes_grid/figures/. This might > require cherry-picking a50874b711983cba505e which was the commit that > Michael used to restore some of the mistakes of the commits on May 6th. > > I will leave it up to Darren to figure out exactly what would be the correct > course of action. Thanks, it should be fixed now. -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x RIP, long live v1.0.x-maint
On 06/03/2011 07:21 AM, Benjamin Root wrote: > P.S. : As an interesting aside to what caused me to find this mistake... > My docs were still not building correctly, although now that the v1.0.x > branch is fixed, it didn't have the multiprocessing trick that is in > master. Therefore, when the error occurred, a message was able to be > printed to my screen, which allows me to trace it down. > > What happens is that eventually, the python debugger is fired off by > sphinx. If possible, it would probably be wise to disable this behavior Ben, So this part of the problem sounds like a bad design in sphinx, correct? Do you know whether it is present in the current version of sphinx? If so, you might send the sphinx people a bug report. My suspicion is that the triggering of pdb was intended to be temporary (or at least optional), but got left in the sphinx code by mistake--if that is indeed where the fault lies. Eric > as it makes no sense for doc-building. What triggers the startup of pdb > is that the copying of simple_axes_divider2.py fails at line 403 of > plot_directive.py, in _plot_directive(). This failure, however, is > actually not the first error, as the first one gets swallowed by a > try...finally statement at line 230, in run_code() of the same file. > > Because of the removal of the .py files as noted above, I only had .pyc > files in that directory, which lead to the build system thinking that > there was content to build. I see these assumptions as being > problematic, and should probably be rethought in the future. > -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x RIP, long live v1.0.x-maint
On Fri, Jun 3, 2011 at 1:52 PM, Eric Firing wrote: > On 06/03/2011 07:21 AM, Benjamin Root wrote: > > > P.S. : As an interesting aside to what caused me to find this mistake... > > My docs were still not building correctly, although now that the v1.0.x > > branch is fixed, it didn't have the multiprocessing trick that is in > > master. Therefore, when the error occurred, a message was able to be > > printed to my screen, which allows me to trace it down. > > > > What happens is that eventually, the python debugger is fired off by > > sphinx. If possible, it would probably be wise to disable this behavior > > Ben, > > So this part of the problem sounds like a bad design in sphinx, correct? > Do you know whether it is present in the current version of sphinx? > If so, you might send the sphinx people a bug report. My suspicion is > that the triggering of pdb was intended to be temporary (or at least > optional), but got left in the sphinx code by mistake--if that is indeed > where the fault lies. > > Eric > I will investigate that further. Currently I am using v1.0.1 of sphinx. After the current round of docs are tested and pushed up, I will take a deeper look. By the way, whoever is the one to push the docs up to sourceforge, you can now do so from the v1.0.x-maint branch. I have built it on my computer and all of my own changes appear correct. I couldn't test *everything* (my LaTeX setup isn't quite right), but everything I intended to change appears to be there. 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.0.x RIP, long live v1.0.x-maint
On Fri, Jun 3, 2011 at 3:37 PM, Benjamin Root wrote: > By the way, whoever is the one to push the docs up to sourceforge, you can > now do so from the v1.0.x-maint branch. I have built it on my computer and > all of my own changes appear correct. I couldn't test *everything* (my > LaTeX setup isn't quite right), but everything I intended to change appears > to be there. > > I just pushed the doc build from the maint branch up to sf. Take it for a test drive. Thanks for pushing through on the doc fix patch. JDH -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
