[Numpy-discussion] Going toward time-based release ?

[Jarrod Millman]

On Sun, May 11, 2008 at 10:42 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
> I dunno. I tend to agree with  Mike Ressler that Numpy really shouldn't
> change very quickly. We can add new features now and then, or move more
> stuff to type specific functions, but those aren't really user visible. Most
> work, I think, should go into tests, cleaning up the code base and
> documenting it, and fixing bugs. I also wonder how good a position we are in
> if Travis decides that there are other things he would rather spend his time
> on. Documentation and clean code will help with that. So I really don't see
> that we need much in the way of scheduled releases except to crack the whip
> on us lazy souls who let things ride until we don't have a choice.  If we do
> have scheduled realeases, then I think it will also be necessary to draw up
> a plan for each release, i.e., cleanup  and document ufuncobject.c.src, and
> so on.

I don't think there is anyone who believes that NumPy should change
very quickly.  Let's try and drop that discussion.  I am worried that
if people keep bring up this straw man argument that our users will
get the impression that we are preparing to break a lot of their code.
 Besides that changes to MA, there has been very few discussions about
changing code.  The discussions that have happened have been met with
numerous comments by several developers that we need to be extremely
conservative about making API changes.  Even for the matrices
discussion it seems that very few people are pushing for us to make
any changes and of those that are most are thinking carefully about
how to cause as little code breakage as possible.  I know that just
recently some matrices changes were made that have caused some
problems, but I am going to rollback those changes.

I think the main issue is that we need to have more regular releases
of NumPy and SciPy.  For NumPy you are completely correct that most
(if not all) of the work should be focused on "tests, cleaning up the
code base and documenting it, and fixing bugs."  The overriding reason
that necessitates a 1.2 release at the end of August is the move to
the nose testing framework.  I feel that this change is extremely
important and want it to take place as quickly as possible.
Personally, I don't have any other major changes that I will champion
getting into 1.2.  The only other major change that has been put forth
so far is the matrix change, which I personally don't think should
change the default behavior in the 1.2 release.

I also really like your suggestion to draw up plans for each release.
And I would love it if you would be willing to take the lead on
something for 1.2 like "cleaning up  and documenting
ufuncobject.c.src."  I would encourage you to start thinking about
whether you could commit to something like that and, if so, creating a
ticket for it briefly describing your plan.

The other thing to consider is how best to coordinate NumPy and SciPy
releases.  There are occasionally times when we need to add or fix
things in a NumPy release before the next SciPy release.  While we
shouldn't expect to see many changes in NumPy, I believe that there is
a *slightly* greater tolerance for changes in SciPy.  As you will
recall, the whole MA change arose from my push to get rid of
scipy.sandbox.  While in retrospect the change could have been handled
better, it is nice that that code has been removed from scipy.sandbox.

I also am extremely happy with all the time and effort that Pierre
spent on writing the MaskedArray.  I want to make it absolutely clear
that all the good, hard work was his and that the transition mistakes
were mine, not his.  I also want to thank Stefan who spent an entire
night preparing for the merge during the December sprint (the time
difference between Berkeley and South Africa makes working at the same
time logistically difficult for him).

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/