[Numpy-discussion] merging datetime progress

Mark Wiebe mwwiebe@gmail....
Wed Jun 8 13:55:32 CDT 2011

On Wed, Jun 8, 2011 at 1:04 PM, Bruce Southey <bsouthey@gmail.com> 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...


> Bruce
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20110608/71cf6314/attachment.html 

More information about the NumPy-Discussion mailing list