31.01.2016, 12:57, Julian Taylor kirjoitti: [clip]
Testing or delegating testing of least our major downstreams should be the job of the release manager. Thus I also disagree with our more frequent releases. It puts too much porting and testing effort on our downstreams and it gets infeaseble for a volunteer release manager to handle. I fear by doing this we will end up in an situation where more downstreams put upper bounds on their supported numpy releases like e.g. astropy already did. This has bad consequences like the subclass breaking of linspace that should have been caught month ago but was not because upstreams were discouraging users from upgrading numpy because they could not keep up with porting.
I'd suggest that some automation could reduce the maintainer burden here. Basically, I think being aware of downstream breakage is something that could be determined without too much manual intervention. For example, automated test rig that does the following: - run tests of a given downstream project version, against previous numpy version, record output - run tests of a given downstream project version, against numpy master, record output - determine which failures were added by the new numpy version - make this happen with just a single command, eg "python run.py", and implement it for several downstream packages and versions. (Probably good to steal ideas from travis-ci dependency matrix etc.) This is probably too time intensive and waste of resources for Travis-CI, but could be run by the Numpy maintainer or someone else during release process, or periodically on some ad-hoc machine if someone is willing to set it up. Of course, understanding the cause of breakages would take some understanding of the downstream package, but this would at least ensure we are aware of stuff breaking. Provided it's covered by downstream test suite, of course. -- Pauli Virtanen