[Numpy-discussion] Current datetime pull requests ready for review

[Charles R Harris]

On Wed, Jun 8, 2011 at 4:09 PM, Benjamin Root <ben.root at ou.edu> wrote:

> On Wednesday, June 8, 2011, Mark Wiebe <mwwiebe at gmail.com> wrote:
> > I've been trying to separate out the features I've been doing into
> separate branches so I can split up into multiple pull, but the development
> I'm doing works pretty poorly with this workflow. Nearly every step of
> development builds on or uses changes from previous features. Since github
> doesn't do dependent pull requests, I'm going to go back to developing in a
> single branch to merge into master periodically.
> >
> > There are currently two pull requests ready to go, which could use some
> review:
> > "Datetime unit from string" https://github.com/numpy/numpy/pull/85
> >
> > This makes conversion from a string to a datetime scalar automatically
> detect the unit if it's not specified. To support the same idea for arrays
> will require adding generic time units as I described in another email.
> >
> > "Unify datetime/timedelta type promotion"
> https://github.com/numpy/numpy/pull/86
> >
> > This simplifies the rules of how datetimes and timedeltas combine to
> always take the gcd/more precise unit instead of having the various special
> cases as the NEP described. The motivation for this change was based on how
> restricting those rules felt after spending some time experimenting with
> datetime calculations.
> >
> > Please review!
> > Cheers,Mark
> >
>
> Just a thought. I think one way to do something like dependent pull
> requests is to develop each feature in it's own branch, and then have
> a branch that would merge some of those feature branches.  These
> branches would represent the logical dependencies needed, and could be
> arbitrarially nested.
>
>  It wouldn't quite be exactly what you are wanting, but maybe
> something similar could be done with pull requests, since one can
> continue developing in a branch until the pull is done.
>
> Just thinking out loud...
>
>
I don't think it is generally possible to develop in a straight line,
breaking things up into a nice sequence can probably only be done after the
fact and it takes work. There is a trade off here as to how the scarce
resource of developer time gets allocated between the tasks. Mark is a very
productive guy so the stuff just piles up and there aren't that many doing
review. OTOH, doing review is much easier if the chunks are smaller.
Probably a bit more time should to go into producing and polishing the
chunks but just how to make that division of labor is probably something we
will only arrive at with some experience.

As to the current problem, we could probably spend some time thinking about
how we use types in writing numpy code. There is some tension between the c
types and the numpy types that I notice even when looking at the sorting
code where the functions are currently associated with c types rather than
numpy sized types.

And let's not forget the useful experience one gains by breaking the trunk
now and then. It makes one more cognizant of what can go wrong and a bit
more careful in the future.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110608/3ff14768/attachment.html>