[Numpy-discussion] NumPy 1.7 release delays

[Ondřej Čertík]

On Tue, Jun 26, 2012 at 4:59 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Tue, Jun 26, 2012 at 1:10 PM, Travis Oliphant <travis at continuum.io> wrote:
>> One issues is the one that Sage identified about the array interface
>> regression as noted by Jason.    Any other regressions from 1.5.x need to be
>> addressed as well.    We'll have to decide on a case-by-case basis if there
>> are issues that conflict with 1.6.x behavior.
>>
>
> One thing this discussion made me think about, is that it would be
> great to identify a few key projects that:
>
> - use numpy heavily
> - have reasonably solid test suites
>
> and create a special build job that runs *those* test suites
> periodically.  Not necessarily on every last numpy commit, but at
> least on a reasonable schedule.
>
> I think having that kind of information readily available, and with
> the ability to switch which numpy branch/commit those tests do get run
> against, could be very valuable as an early warning system for numpy
> to know if an apparently inconsequential change has unexpected side
> effects downstream.


I think that is a great idea. It would simply recompile numpy,
but leave the other library intact, and then run some tests on the
other library,
which could be as simple as "import h5py", or more complicated.

>
> In IPython we've really benefited greatly from our improved CI
> infrastructure, but that only goes as far as catching *our own*

Do you use anything else besides Travis CI?
I donated money to them and they enabled pull request
testing for SymPy and it's invaluable. We also use
our custom sympy-bot (https://github.com/sympy/sympy-bot) to test pull
request, but now
when Travis can do that, we might just use that.

NumPy now has Travis for both master and pull requests and so
it is pretty well covered.

I need to setup some Jenkins instances for Windows (and Mac) testing,
and then we can also add linux Jenkins instance to test numpy
against a few other libraries.


> problems.  This kind of downstream integration testing could be very
> useful.


Ondrej