[Numpy-discussion] merging datetime progress

[Fernando Perez]

On Tue, Jun 7, 2011 at 4:35 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
> I went ahead and did the merge today as I said I wanted to, that pull
> request is some further development for someone to code-review if they have
> time.

I'm curious as to why there was a need to push ahead with the merge
right away, without giving the original pull request more time for
feedback?  If I'm not mistaken, the big merge was this PR:

https://github.com/numpy/numpy/pull/83

and it was just opened a few days ago, containing a massive amount of
work, and so far had only received some feedback from charris,
explicitly requesting a little more breakdown to make digesting it
easier.

I realize that I'm not really an active numpy contributor in any
significant way, and I see that you've put a ton of work into this,
including a very detailed and impressive discussion on the list on
with multiple people.  So my opinion is just that of a user, not
really a core numpy developer.

But it seems to me that part of having numpy be a better
community-driven project is precisely achieved by having the patience
to allow others to provide feedback and testing, even if they aren't
100% experts.  And one thing that github really shines at, is making
the review/feedback process about as painless as possible (I actually
find it kind of fun).

For example, with this merge, numpy HEAD right now won't even compile
on x86_64, something that would easily have been caught with a bit
more review, especially since it's so easy to test (even I can do
that).  It's been a long time since we had a situation where numpy
didn't cleanly at least build from HEAD, so if nothing else, it's a
(small) sign that this particular merge could have used a few more
eyes...

I realize that it's sometimes frustrating to have a lot of code
sitting in review, and I know that certain efforts are large and
self-contained enough that it's impractical to expect a detailed
line-by-line review.  We've had a few such monster branches in ipython
in the past, but at least in those cases we've always tried to ensure
several core people (over skype if needed) have a chance to go over
the entire big picture, discuss the main details with the author so
they can know what to focus on from the large merge, and run the tests
in as many scenarios as is realistic.  And so far we haven't really
had any problems with this approach, even if it does require a little
more patience in seeing that (often very high quality) work make it to
the mainline.

Regards,

f