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

[Mark Wiebe]

On Wed, Jun 8, 2011 at 6:53 PM, Charles R Harris
<charlesr.harris at gmail.com>wrote:

>
>
> 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.
>

Yeah, one thing I'm trying to do in my recent commits is elaborate slightly
more in the commit messages and make the commits slightly smaller. Maybe
making topic-related tags in the commit messages might be a way to help
group related commits without having to muck about with history-editing. I'm
open to trying out all kinds of suggestions.

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.
>

I think the code backing this aspect of the system basically belongs in a
low-level "libdatatype" to encapsulate the meaning of a data type to numpy.
If we want to add, say, integers mod n, integers with a NaN value,
quaternions, etc, having a systematic backing which allows for minimal work
to add a new type will be very helpful.

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.
>

Allowing such breakages, but requiring responsive fixes from those that
cause them, is probably a good policy for letting in more developers. If
people are paralyzed from making changes because they might break something,
they're not going to be very productive at creating more functionality.

Cheers,
Mark


>
> Chuck
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110608/c5acb48d/attachment.html>