<br><br><div class="gmail_quote">On Wed, Jun 8, 2011 at 4:09 PM, Benjamin Root <span dir="ltr">&lt;<a href="mailto:ben.root@ou.edu">ben.root@ou.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Wednesday, June 8, 2011, Mark Wiebe &lt;<a href="mailto:mwwiebe@gmail.com">mwwiebe@gmail.com</a>&gt; wrote:<br>
&gt; I&#39;ve been trying to separate out the features I&#39;ve been doing into separate branches so I can split up into multiple pull, but the development I&#39;m doing works pretty poorly with this workflow. Nearly every step of development builds on or uses changes from previous features. Since github doesn&#39;t do dependent pull requests, I&#39;m going to go back to developing in a single branch to merge into master periodically.<br>

&gt;<br>
&gt; There are currently two pull requests ready to go, which could use some review:<br>
&gt; &quot;Datetime unit from string&quot; <a href="https://github.com/numpy/numpy/pull/85" target="_blank">https://github.com/numpy/numpy/pull/85</a><br>
&gt;<br>
&gt; This makes conversion from a string to a datetime scalar automatically detect the unit if it&#39;s not specified. To support the same idea for arrays will require adding generic time units as I described in another email.<br>

&gt;<br>
&gt; &quot;Unify datetime/timedelta type promotion&quot; <a href="https://github.com/numpy/numpy/pull/86" target="_blank">https://github.com/numpy/numpy/pull/86</a><br>
&gt;<br>
&gt; 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.<br>

&gt;<br>
&gt; Please review!<br>
&gt; Cheers,Mark<br>
&gt;<br>
<br>
</div></div>Just a thought. I think one way to do something like dependent pull<br>
requests is to develop each feature in it&#39;s own branch, and then have<br>
a branch that would merge some of those feature branches.  These<br>
branches would represent the logical dependencies needed, and could be<br>
arbitrarially nested.<br>
<br>
 It wouldn&#39;t quite be exactly what you are wanting, but maybe<br>
something similar could be done with pull requests, since one can<br>
continue developing in a branch until the pull is done.<br>
<br>
Just thinking out loud...<br>
<br></blockquote><div><br>I don&#39;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&#39;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.<br>
<br>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.<br>
<br>And let&#39;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.<br><br>Chuck<br><br></div></div>