Re: [Numpy-svn] r5198 - trunk/numpy/f2py

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Numpy-svn] r5198 - trunk/numpy/f2py

Pearu Peterson-3
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
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Numpy-svn] r5198 - trunk/numpy/f2py

Stéfan van der Walt
Hi Pearu

2008/5/20 Pearu Peterson <[hidden email]>:

> 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
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Numpy-svn] r5198 - trunk/numpy/f2py

Pearu Peterson-3


Stéfan van der Walt wrote:

> Hi Pearu
>
> 2008/5/20 Pearu Peterson <[hidden email]>:
>> 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.

Yes. There is no other place.

>> 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?

Note that in past f2py was developed using a bit different model
compared to what we require for numpy currently.
The g3 f2py development will be carried out out of numpy tree
but using numpy development model.

Switching numpy.f2py to numpy development model requires substantial
changes, most dramatic one would be to remove f2py;).
A realistic change would require working out a way to test
automatically generated extension modules.
Since this requires existence of C and *Fortran* compilers,
then the test runner must be able to detect the existence of compilers
in order to decide whether to run such tests or not.

So I beg to be flexible with f2py related commits for now. Most changes
are tested by me to ensure that f2py works correctly (as a minimum,
after changing f2py, I always test f2py against scipy).
Some changes may need users feedback because I may
not have access to all commercial Fortran compilers that numpy.distutis
aims at supporting. This development model has not broke f2py in past
as far as I have been concerned. If you will disallow such bug fixes
in future, it would mean that maintaining f2py in numpy will be
practically stopped. I am not sure that we would want that either.

Pearu
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Numpy-svn] r5198 - trunk/numpy/f2py

cdavid
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
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Numpy-svn] r5198 - trunk/numpy/f2py

Pearu Peterson-3


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
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Numpy-svn] r5198 - trunk/numpy/f2py

cdavid
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
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Numpy-svn] r5198 - trunk/numpy/f2py

Pearu Peterson-3
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
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Numpy-svn] r5198 - trunk/numpy/f2py

Jarrod Millman
In reply to this post by Pearu Peterson-3
On Mon, May 19, 2008 at 10:29 PM, Pearu Peterson <[hidden email]> 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
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Numpy-svn] r5198 - trunk/numpy/f2py

Jarrod Millman
In reply to this post by Pearu Peterson-3
On Tue, May 20, 2008 at 1:00 AM, Pearu Peterson <[hidden email]> 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
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: [Numpy-svn] r5198 - trunk/numpy/f2py

Pearu Peterson-3
In reply to this post by Jarrod Millman
On Tue, May 20, 2008 1:36 pm, Jarrod Millman wrote:

> On Mon, May 19, 2008 at 10:29 PM, Pearu Peterson <[hidden email]>
> 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
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion