Menu
▾
▴
matplotlib-devel
|
From: Benjamin R. <ben...@ou...> - 2011-01-06 19:25:22
Attachments:
exampledirpath.patch
|
On Thu, Jan 6, 2011 at 12:32 PM, John Hunter <jd...@gm...> wrote: > On Thu, Jan 6, 2011 at 12:22 PM, John Hunter <jd...@gm...> wrote: > > > matplotlib_fname() always returns absolute path. I have not used > > realpath, but if you think there is a use for it here, feel free to > > post an amended patch. > > There is an exception to this -- if MATPLOTLIBRC or MPLCONFIGDIR are > relative paths, then matplotlib_fname will return a relative path too. > Ah, all the more reason to apply abspath() or realpath(). To decide which to use, let's consider the case of someone (like a developer) having multiple builds of matplotlib in separate directories, and uses a symlink to point to whichever he wants to use at the moment. The question is, in this use-case, would we want the symbolic link pathname, or the absolute pathname? I don't mess around with docs enough to know which I would want. I have attached a modified patch (which uses realpath(), but could easily be changed to abspath()). I also included some comments to more fully document what is going on and the rational for the logic being taken. Ben Root P.S. - Just to make sure, I noticed that rcParamsOrig is only in the maintenance branch. It was intended to leave the development branch "broken" for now until we get this working properly? |
|
From: John H. <jd...@gm...> - 2011-01-06 19:58:17
|
On Thu, Jan 6, 2011 at 1:24 PM, Benjamin Root <ben...@ou...> wrote: > Ah, all the more reason to apply abspath() or realpath(). To decide which > to use, let's consider the case of someone (like a developer) having > multiple builds of matplotlib in separate directories, and uses a symlink to > point to whichever he wants to use at the moment. > > The question is, in this use-case, would we want the symbolic link pathname, > or the absolute pathname? I don't mess around with docs enough to know > which I would want. > > I have attached a modified patch (which uses realpath(), but could easily be > changed to abspath()). I also included some comments to more fully document > what is going on and the rational for the logic being taken. OK, I incorporated your changes and committed. Thanks. > P.S. - Just to make sure, I noticed that rcParamsOrig is only in the > maintenance branch. It was intended to leave the development branch > "broken" for now until we get this working properly? That's correct, but I just did a big merge of all the branch changes so the trunk is fixed as well now. JDH |
|
From: Sandro T. <mo...@de...> - 2011-01-11 00:23:04
|
Hi John, On Thu, Jan 6, 2011 at 20:57, John Hunter <jd...@gm...> wrote: > On Thu, Jan 6, 2011 at 1:24 PM, Benjamin Root <ben...@ou...> wrote: >> Ah, all the more reason to apply abspath() or realpath(). To decide which >> to use, let's consider the case of someone (like a developer) having >> multiple builds of matplotlib in separate directories, and uses a symlink to >> point to whichever he wants to use at the moment. >> >> The question is, in this use-case, would we want the symbolic link pathname, >> or the absolute pathname? I don't mess around with docs enough to know >> which I would want. >> >> I have attached a modified patch (which uses realpath(), but could easily be >> changed to abspath()). I also included some comments to more fully document >> what is going on and the rational for the logic being taken. > > OK, I incorporated your changes and committed. Thanks. Just to be sure: this patch is *not* in the released 1.0.1 tarball (and it will be included in the next released version), is that correct? Anyhow, with a bit of hackery in our building process, I'm able to prepare Debian packages without download anything from the net: thanks a lot for your support throughout all the process!! Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: Benjamin R. <ben...@ou...> - 2011-01-11 00:45:58
|
John, Just to clarify, have we officially released 1.0.1, or are we still in the RC phase? If we haven't released yet, what is the deadline for final patches for 1.0.1? Ben Root |
|
From: John H. <jd...@gm...> - 2011-01-11 21:13:45
|
On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou...> wrote: > John, > > Just to clarify, have we officially released 1.0.1, or are we still in the > RC phase? If we haven't released yet, what is the deadline for final > patches for 1.0.1? > 1.0.1 is final but I held off on the announcement until Russel got the OSX builds uploaded (which he did yesterday, but I still haven't gotten to the announcement). If there are significant problems (eg the 3D stuff you reported or other issues) I have no problem pushing out 1.0.2 quickly. JDH |
|
From: Benjamin R. <ben...@ou...> - 2011-01-12 17:21:17
|
On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jd...@gm...> wrote: > On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou...> wrote: > > John, > > > > Just to clarify, have we officially released 1.0.1, or are we still in > the > > RC phase? If we haven't released yet, what is the deadline for final > > patches for 1.0.1? > > > > 1.0.1 is final but I held off on the announcement until Russel got the > OSX builds uploaded (which he did yesterday, but I still haven't > gotten to the announcement). If there are significant problems (eg > the 3D stuff you reported or other issues) I have no problem pushing > out 1.0.2 quickly. > > JDH > John, I am fine with letting 1.0.1 go out as is (unless we can't live with the documentation typos that has shown up). I am also hesistant about putting out yet another bug-fix release because there will be distros that will have 1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into a maintenance nightmare. Instead, let's just let those package maintainers keep up with the patches to 1.0.1. This also raises a question. When putting out maintenance patches, are we going to have to patch 1.0.0 and 1.0.1? I think what happened with 1.0.1 is that while there were some clear goals (solidification of the backend codes and getting the no-download doc feature working), it also became a bit of a free-for-all for receiving other patches (I am guilty of this). Personally, I lost sight of the point of the RCs and that is to seek out and squash only the show-stopper bugs. Any other patches should not go in. Looking forward, I think there are a couple of things that we can do for the next release (1.1.0?) that would be greatly beneficial. First, I think having a clear and firm (but not set-in-stone) release date is important. Second, release candidates should probably be made available for a couple of weeks. Third, I think when it comes time for a release, there should be at least one or two other developers agreeing on the release (the purpose of this is to give a last-chance for any objections, and to share the responsibility of the release). Last, there should probably be clearer goals/milestones for the releases. I would appreciate any thoughts/comments on this. We can start up a new thread if it is more appropriate. Ben Root |
|
From: Sandro T. <mo...@de...> - 2011-01-12 19:09:58
|
On Wed, Jan 12, 2011 at 18:20, Benjamin Root <ben...@ou...> wrote: > I am fine with letting 1.0.1 go out as is (unless we can't live with the is already out: look at SF download page to see how many have downloaded it. > documentation typos that has shown up). I am also hesistant about putting > out yet another bug-fix release because there will be distros that will have > 1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into a > maintenance nightmare. Instead, let's just let those package maintainers > keep up with the patches to 1.0.1. > > This also raises a question. When putting out maintenance patches, are we > going to have to patch 1.0.0 and 1.0.1? If you're saying you want to publish another tarball with version 1.0.1 that has different contents of the current one, than with my distro package maintainer and programmer hats on I say "you should not". If you have published (and not advertised, ok) something, you cannot re-publish the same version but with something "different" in it. Just go with 1.0.2, distros have (usually) the latest version and you are free to release patches in the HEAD of your development tree: it's a distro package maintainer evaluate if this patches are to be backported to the distro version, if the version cannot be bring up-to-date with the latest release. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: John H. <jd...@gm...> - 2011-01-12 20:23:20
|
On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi <mo...@de...> wrote: > If you're saying you want to publish another tarball with version > 1.0.1 that has different contents of the current one, than with my > distro package maintainer and programmer hats on I say "you should > not". If you have published (and not advertised, ok) something, you > cannot re-publish the same version but with something "different" in > it. Just go with 1.0.2, distros have (usually) the latest version and > you are free to release patches in the HEAD of your development tree: > it's a distro package maintainer evaluate if this patches are to be > backported to the distro version, if the version cannot be bring > up-to-date with the latest release. Exactly, once we upload a version with a number, it is fixed. It becomes really difficult to debug when two people think they are using the same code and looking at different bases. |
|
From: Benjamin R. <ben...@ou...> - 2011-01-13 00:29:25
|
On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi <mo...@de...> wrote: > On Wed, Jan 12, 2011 at 18:20, Benjamin Root <ben...@ou...> wrote: > > I am fine with letting 1.0.1 go out as is (unless we can't live with the > > is already out: look at SF download page to see how many have downloaded > it. > > > documentation typos that has shown up). I am also hesistant about > putting > > out yet another bug-fix release because there will be distros that will > have > > 1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into > a > > maintenance nightmare. Instead, let's just let those package maintainers > > keep up with the patches to 1.0.1. > > > > This also raises a question. When putting out maintenance patches, are > we > > going to have to patch 1.0.0 and 1.0.1? > > If you're saying you want to publish another tarball with version > 1.0.1 that has different contents of the current one, than with my > distro package maintainer and programmer hats on I say "you should > not". If you have published (and not advertised, ok) something, you > cannot re-publish the same version but with something "different" in > it. Just go with 1.0.2, distros have (usually) the latest version and > you are free to release patches in the HEAD of your development tree: > it's a distro package maintainer evaluate if this patches are to be > backported to the distro version, if the version cannot be bring > up-to-date with the latest release. > > Cheers, > I believe we are actually in agreement, but perhaps I wasn't clear enough. The maintenance patches that I speak of are committed in the v1_0_maint branch of the svn repo. The tarball still has the original code from the release point regardless of what patches have been committed since then. Package maintainers can choose to cherry-pick those patches or even track that maintenance branch for their own packaging purposes. The point is that new features should not be added (unless absolutely necessary) and that old features are not removed on that branch. Please see our coding guide under "Committing Changes" (particularly the last bullet): > Keep the maintenance branch (0.91) the latest release branch (eg 0.98.4) > and trunk in sync where it makes sense. If there is a bug on both that needs > fixing, use svnmerge.py <http://www.orcaware.com/svn/wiki/Svnmerge.py> to > keep them in sync. > So, back to the issue regarding whether to put out a 1.0.2 or not. We will always be wanting to patch things (lord knows there are enough bugs...) and at some point we have to say "it is good enough". Right now, my only major qualm with the current 1.0.1 release has been the documentation (by the way, the Coding Guide page looks terrible on my small screen). Code-wise, I am willing to accept it as is and start focusing on 1.1.0. Ben Root |
|
From: Eric F. <ef...@ha...> - 2011-01-12 18:57:00
|
On 01/12/2011 07:20 AM, Benjamin Root wrote: > On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jd...@gm... > <mailto:jd...@gm...>> wrote: > > On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou... > <mailto:ben...@ou...>> wrote: > > John, > > > > Just to clarify, have we officially released 1.0.1, or are we > still in the > > RC phase? If we haven't released yet, what is the deadline for final > > patches for 1.0.1? > > > > 1.0.1 is final but I held off on the announcement until Russel got the > OSX builds uploaded (which he did yesterday, but I still haven't > gotten to the announcement). If there are significant problems (eg > the 3D stuff you reported or other issues) I have no problem pushing > out 1.0.2 quickly. > > JDH > > > John, > > I am fine with letting 1.0.1 go out as is (unless we can't live with the > documentation typos that has shown up). I am also hesistant about > putting out yet another bug-fix release because there will be distros > that will have 1.0.0, 1.0.1, and then possibly others with 1.0.2, which > would turn into a maintenance nightmare. Instead, let's just let those > package maintainers keep up with the patches to 1.0.1. > > This also raises a question. When putting out maintenance patches, are > we going to have to patch 1.0.0 and 1.0.1? > > I think what happened with 1.0.1 is that while there were some clear > goals (solidification of the backend codes and getting the no-download > doc feature working), it also became a bit of a free-for-all for > receiving other patches (I am guilty of this). Personally, I lost sight > of the point of the RCs and that is to seek out and squash only the > show-stopper bugs. Any other patches should not go in. > > Looking forward, I think there are a couple of things that we can do for > the next release (1.1.0?) that would be greatly beneficial. First, I > think having a clear and firm (but not set-in-stone) release date is > important. Second, release candidates should probably be made available > for a couple of weeks. Third, I think when it comes time for a release, > there should be at least one or two other developers agreeing on the > release (the purpose of this is to give a last-chance for any > objections, and to share the responsibility of the release). Last, > there should probably be clearer goals/milestones for the releases. > > I would appreciate any thoughts/comments on this. We can start up a new > thread if it is more appropriate. > > Ben Root > Ben, It sounds like what you are talking about is more like the way numpy has been working, complete with a release manager. Would you be willing and able to take on that role, along with all the other excellent work you have been doing? It would be a big step forward for mpl, I think. Eric |
|
From: Benjamin R. <ben...@ou...> - 2011-01-13 00:36:55
|
On Wed, Jan 12, 2011 at 12:56 PM, Eric Firing <ef...@ha...> wrote: > On 01/12/2011 07:20 AM, Benjamin Root wrote: > > On Tue, Jan 11, 2011 at 3:13 PM, John Hunter <jd...@gm... > > <mailto:jd...@gm...>> wrote: > > > > On Mon, Jan 10, 2011 at 6:45 PM, Benjamin Root <ben...@ou... > > <mailto:ben...@ou...>> wrote: > > > John, > > > > > > Just to clarify, have we officially released 1.0.1, or are we > > still in the > > > RC phase? If we haven't released yet, what is the deadline for > final > > > patches for 1.0.1? > > > > > > > 1.0.1 is final but I held off on the announcement until Russel got > the > > OSX builds uploaded (which he did yesterday, but I still haven't > > gotten to the announcement). If there are significant problems (eg > > the 3D stuff you reported or other issues) I have no problem pushing > > out 1.0.2 quickly. > > > > JDH > > > > > > John, > > > > I am fine with letting 1.0.1 go out as is (unless we can't live with the > > documentation typos that has shown up). I am also hesistant about > > putting out yet another bug-fix release because there will be distros > > that will have 1.0.0, 1.0.1, and then possibly others with 1.0.2, which > > would turn into a maintenance nightmare. Instead, let's just let those > > package maintainers keep up with the patches to 1.0.1. > > > > This also raises a question. When putting out maintenance patches, are > > we going to have to patch 1.0.0 and 1.0.1? > > > > I think what happened with 1.0.1 is that while there were some clear > > goals (solidification of the backend codes and getting the no-download > > doc feature working), it also became a bit of a free-for-all for > > receiving other patches (I am guilty of this). Personally, I lost sight > > of the point of the RCs and that is to seek out and squash only the > > show-stopper bugs. Any other patches should not go in. > > > > Looking forward, I think there are a couple of things that we can do for > > the next release (1.1.0?) that would be greatly beneficial. First, I > > think having a clear and firm (but not set-in-stone) release date is > > important. Second, release candidates should probably be made available > > for a couple of weeks. Third, I think when it comes time for a release, > > there should be at least one or two other developers agreeing on the > > release (the purpose of this is to give a last-chance for any > > objections, and to share the responsibility of the release). Last, > > there should probably be clearer goals/milestones for the releases. > > > > I would appreciate any thoughts/comments on this. We can start up a new > > thread if it is more appropriate. > > > > Ben Root > > > > Ben, > > It sounds like what you are talking about is more like the way numpy has > been working, complete with a release manager. Would you be willing and > able to take on that role, along with all the other excellent work you > have been doing? It would be a big step forward for mpl, I think. > > Eric > > I agree, I think that is the direction MPL needs to go. We are feature-packed, but still have a lot of rough edges. The prospect of being a release manager is great, but it will depend on when we plan to release if I will have enough time to devote to that. Ben Root |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X