Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
Hi Pearu 2008/5/20 Pearu Peterson [EMAIL PROTECTED]: CC: numpy-discussion because of other reactions on the subject. On Tue, May 20, 2008 1:26 am, Robert Kern wrote: Is this an important bugfix? If not, can you hold off until 1.1.0 is released? The patch fixes a long existing and unreported bug in f2py - I think the bug was introduced when Python defined min and max functions. I learned about the bug when reading a manuscript about f2py. Such bugs should not end up in a paper demonstrating f2py inability to process certain features as it would have not been designed to do so. So, I'd consider the bugfix important. On the other hand, the patch does not affect numpy users who do not use f2py, in any way. So, it is not important for numpy users, in general. Many f2py users currently get their version via NumPy, I assume. Hmm, I also thought that the trunk is open for development, even though r5198 is only fixing a bug (and I do not plan to develop f2py in numpy further, just fix bugs and maintain it). If the release process is going to take for weeks and is locking the trunk, may be the release candidates should live in a separate branch? If the patch a) Fixes an important bug and b) has unit tests to ensure it does what it is supposed to then I'd be +1 for applying. It looks like there are some tests included; to which degree do they cover the bugfix, and do we have tests to make sure that f2py still functions correctly? I'd like to make sure I understood Jarrod's message from earlier this week: 1) Release candidate branch is tagged -- development continues on trunk 2) Release candidate is tested 3) Bug-fixes are back-ported to the release candidate as necessary 4) Release is made Another version I've seen starts with: 1) Release candidate branch is tagged -- no one touches trunk except for bug-fixes Which is it? I want to know where the docstring changes should go. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
Pearu Peterson wrote: So I beg to be flexible with f2py related commits for now. Why not creating a branch for the those changes, and applying only critical bug fixes to the trunk ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
David Cournapeau wrote: Pearu Peterson wrote: So I beg to be flexible with f2py related commits for now. Why not creating a branch for the those changes, and applying only critical bug fixes to the trunk ? How do you define a critical bug? Critical to whom? f2py changes are never critical to numpy users who do not use f2py. I have stated before that I am not developing numpy.f2py any further. This also means that any changes to f2py should be essentially bug fixes. Creating a branch for bug fixes is a waste of time, imho. If somebody is willing to maintain the branch, that is, periodically sync the branch with the trunk and vice-versa, then I don't mind. Pearu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
Pearu Peterson wrote: f2py changes are never critical to numpy users who do not use f2py. No, but they are to scipy users if f2py cannot build scipy. I have stated before that I am not developing numpy.f2py any further. This also means that any changes to f2py should be essentially bug fixes. Creating a branch for bug fixes is a waste of time, imho. I was speaking about creating a branch for the unit tests changes you were talking about, that is things which could potentially break a lot of configurations. Is the new f2py available for users ? If yes, you should tell f2py users to use this, and just do not care at all about numpy.f2py anymore, except for critical bugs. Maintaining two versions of the same software is always a PITA, so if you don't want to spend time on it, just focus on the new f2py (as long as numpy.f2py can build scipy, of course). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
On Tue, May 20, 2008 12:03 pm, David Cournapeau wrote: Pearu Peterson wrote: f2py changes are never critical to numpy users who do not use f2py. No, but they are to scipy users if f2py cannot build scipy. Well, I know pretty well what f2py features scipy uses and what could break scipy build. So, don't worry about that. I have stated before that I am not developing numpy.f2py any further. This also means that any changes to f2py should be essentially bug fixes. Creating a branch for bug fixes is a waste of time, imho. I was speaking about creating a branch for the unit tests changes you were talking about, that is things which could potentially break a lot of configurations. A branch for the unit tests changes is of course reasonable. Is the new f2py available for users ? If yes,.. No, it is far from being usable now. The numpy.f2py and g3 f2py are completely different software. The changeset was fixing a bug in numpy.f2py, it has nothing to do with g3 f2py. amazing-how-paranoiac-is-todays-numpy/scipy-development'ly yours, Pearu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
On Mon, May 19, 2008 at 10:29 PM, Pearu Peterson [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 1:26 am, Robert Kern wrote: Is this an important bugfix? If not, can you hold off until 1.1.0 is released? The patch fixes a long existing and unreported bug in f2py - I think the bug was introduced when Python defined min and max functions. I learned about the bug when reading a manuscript about f2py. Such bugs should not end up in a paper demonstrating f2py inability to process certain features as it would have not been designed to do so. So, I'd consider the bugfix important. I have been struggling to try and get a stable release out since February and every time I think that the release is almost ready some piece of code changes that requires me to delay. While overall the code has continuously improved over this period, I think it is time to get these improvements to our users. That said, I am willing to leave this change on the trunk, but please refrain from making any more changes until we release 1.1.0. I know it can be frustrating, but, I believe, this is the first time I have asked the community to not make commits to the trunk since I started handling releases almost a year ago. The freeze has only been in effect since Saturday and will last less than one week in total. I would have preferred if you could have made this change during any one of the other 51 weeks of the year. Hmm, I also thought that the trunk is open for development, even though r5198 is only fixing a bug (and I do not plan to develop f2py in numpy further, just fix bugs and maintain it). If the release process is going to take for weeks and is locking the trunk, may be the release candidates should live in a separate branch? Sorry for the confusion, I had asked that everyone be extremely conservative and careful about any commits you make to the trunk until we officially release 1.1.0, which is still pretty much the rule of thumb. I have been keeping the 1.1.0 milestone page up-to-date with regard to my planned release date; but I should have highlighted the date in my email. The main reason that this is happening on the trunk is that about two weeks ago I created a 1.1.x branch, but I didn't think all the bug-fixes for the 1.1.0 release were being made to the branch and the branch and the trunk got out of synch enough that it was difficult for me to merge the fixes in the trunk into the branch, so I deleted the branch and declared the trunk to again be where 1.1.x development occurred. I fully intend to release 1.1.0 by the end of the week. I also intend to create a 1.1.x maintenance branch at that point, so the trunk will be open for 1.2 development. As long as you are only going to be adding bug-fixes to numpy.f2py, I think that you should be able to use the trunk for this purpose once I create the 1.1.x branch. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
On Tue, May 20, 2008 at 1:00 AM, Pearu Peterson [EMAIL PROTECTED] wrote: How do you define a critical bug? Critical to whom? I know that the definition of a critical bug is somewhat ill-defined, but I think that a long existing and unreported bug probably wouldn't fall into the category of critical bug. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
On Tue, May 20, 2008 1:36 pm, Jarrod Millman wrote: On Mon, May 19, 2008 at 10:29 PM, Pearu Peterson [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 1:26 am, Robert Kern wrote: Is this an important bugfix? If not, can you hold off until 1.1.0 is released? The patch fixes a long existing and unreported bug in f2py - I think the bug was introduced when Python defined min and max functions. I learned about the bug when reading a manuscript about f2py. Such bugs should not end up in a paper demonstrating f2py inability to process certain features as it would have not been designed to do so. So, I'd consider the bugfix important. I have been struggling to try and get a stable release out since February and every time I think that the release is almost ready some piece of code changes that requires me to delay. While overall the code has continuously improved over this period, I think it is time to get these improvements to our users. That said, I am willing to leave this change on the trunk, but please refrain from making any more changes until we release 1.1.0. I know it can be frustrating, but, I believe, this is the first time I have asked the community to not make commits to the trunk since I started handling releases almost a year ago. The freeze has only been in effect since Saturday and will last less than one week in total. I would have preferred if you could have made this change during any one of the other 51 weeks of the year. Please, go ahead. I'll not commit non-critical changes until the trunk is open again. Pearu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
CC: numpy-discussion because of other reactions on the subject. On Tue, May 20, 2008 1:26 am, Robert Kern wrote: Is this an important bugfix? If not, can you hold off until 1.1.0 is released? The patch fixes a long existing and unreported bug in f2py - I think the bug was introduced when Python defined min and max functions. I learned about the bug when reading a manuscript about f2py. Such bugs should not end up in a paper demonstrating f2py inability to process certain features as it would have not been designed to do so. So, I'd consider the bugfix important. On the other hand, the patch does not affect numpy users who do not use f2py, in any way. So, it is not important for numpy users, in general. Hmm, I also thought that the trunk is open for development, even though r5198 is only fixing a bug (and I do not plan to develop f2py in numpy further, just fix bugs and maintain it). If the release process is going to take for weeks and is locking the trunk, may be the release candidates should live in a separate branch? Pearu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
