On Wed, Jun 8, 2011 at 1:04 PM, Bruce Southey <[email protected]> wrote:
> ** > > <snip> > > I am sorry but github pull requests do not appear to be sent to the numpy > dev list. So you are not going to get many people to respond to that type of > 'closed' request. Further any discussion for things that get merged into the > master really should be on the list especially as many people do extensive > testing. > This is a good point, would it be possible to add numpy-discussion as a collaborator in the NumPy github repository, so it would get those emails too? The number of pull requests is relatively small, so this wouldn't add a great deal more traffic. > Bug fixes probably do not need further notification but feature additions > or API/ABI changes should have wider notification. So an email to the list > would be greatly appreciated so that interested people can track the request > and any discussions there. Then, depending on the nature of the request, a > second email that notifies that the request will be merged. > I was attempting to provide reasonable notification, but I see the pull request vs numpy-discussion email is an issue. I can understand Windows failures because not that many people build under > Windows but build failures under Linux are rather hard to understand. If you > do not test Python 2.4, 2.5, 2.6, 2.7, 3.1 and 3.2 with the supported > operating systems (mainly 32-bit and 64-bit Linux, Mac and Windows) then you > must let those people who can and give them time to build and test it. That > is really true when you acknowledged that you broke one of the 'one of the > datetime API functions'. > Requiring that amount of overhead before committing a change into master, which is the unstable development branch, sounds very unreasonable to me. I really wish the buildbot system or something equivalent could provide continuous integration testing with minimal developer effort. I also think the default monolithic build mode in setup.py should be removed, and the multi-file approach should just be used, to reduce the number of possible build configurations. I don't want to get sucked into the distutils vortex, however, someone else needs to volunteer to make a change like this. I would prefer for it to be relatively easy for a change to go into master, with quick responses when things break. That's what I'm trying to provide for the problem reports being sent to the list. There's the 1.6.x branch available for people who want stability with the latest bug-fixes. The datetime API already received some discussion near the start of the long datetime thread, with the general response being to mark the datetime functionality as experimental with big warning signs. My interpretation of this is that it is about releases, not the unstable development branch, and view it the same way as when NumPy master was ABI-incompatible until it was decided to fix that approaching the 1.6 release. In this case, the ABI is still compatible with 1.6, and I suspect the datetime API function in question doesn't work as would be expected in 1.6 either. My experience with the new-iterator branch was that while I got some feedback while it was in a branch, only merging into master produced the feedback necessary to get it properly stable. Anyone that's pulling from master is participating in the development process, which can occasionally involve broken builds, crashes, and bugs, and feedback from people doing that is invaluable. I really hope nobody is automatically updating from master in a production system anywhere, if they are they should stop... -Mark > > Bruce > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
