[Numpy-discussion] merging datetime progress
Wed Jun 8 15:23:39 CDT 2011
On Wed, Jun 8, 2011 at 1:55 PM, Mark Wiebe <email@example.com> wrote:
> On Wed, Jun 8, 2011 at 1:04 PM, Bruce Southey <firstname.lastname@example.org> wrote:
>> 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
> 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...
>> NumPy-Discussion mailing list
> NumPy-Discussion mailing list
I do understand and really do appreciate the effort that your putting in.
More information about the NumPy-Discussion