[SciPy-Dev] pull requests and code review

Bruce Southey bsouthey@gmail....
Fri Jan 6 19:38:19 CST 2012


On Thu, Jan 5, 2012 at 8:02 PM,  <josef.pktd@gmail.com> wrote:
> On Thu, Jan 5, 2012 at 8:48 PM, Travis Oliphant <travis@continuum.io> wrote:
>> Understood.   I will listen to the feedback --- apologies to those whose
>> toes feel steeped on by the crazy cousin stepping back into the house.
>>
>> The github process is one I am still not used to in practice. Also,
>> obviously my orientation is towards much faster review cycles which have to
>> happen in industry.
>>
>> I still think it would be useful to have someplace that people could
>> register their interest in modules.  A simple wiki page would be a start, I
>> imagine.
>
> Getting a rough overview of interested people would be useful, but
> most of the time it is just the usual suspects for scipy, given the
> comment history on github.
>
> On a module level it might not be so informative. For example if you
> change signal.lfilter then I would check immediately whether it
> affects statsmodels, but for most other changes I wouldn't be
> interested enough to check the details.
> For the new optimize.minimize I stayed out of the discussion of the
> details, and kept only track of the main design since it doesn't have
> a direct impact on statsmodels but will be useful in future.
>
> Josef
>
>>
>> Travis
>>
>> --
>> Travis Oliphant
>> (on a mobile)
>> 512-826-7480
>>
>>
>> On Jan 5, 2012, at 7:27 PM, Charles R Harris <charlesr.harris@gmail.com>
>> wrote:
>>
>>
>>
>> On Thu, Jan 5, 2012 at 6:02 PM, Travis Oliphant <travis@continuum.io> wrote:
>>>
>>> Wow that is a much different time frame than I would expect or think
>>> necessary.
>>>
>>> Where does this rule of thumb come from?
>>>
>>
>> Experience. Think of it as a conference meeting with low bandwidth.
>>
>>>
>>> It has quite a few implications that I don't think are pleasant.  I would
>>> be quite dissatisfied if my pull requests took 2-3 weeks to get merged.
>>>
>>
>> Join the crowd.
>>
>>>
>>> Is that just your feeling or does that come from empirical data or a
>>> larger vote?
>>>
>>
>> You just got a complaint, that should tell you something ;)
>>
>> You've been out of the loop for a couple of years, you need to take time to
>> feel your way back into things. You may feel that you still own the property
>> but a lot of squatters have moved in while you were gone...
>>
>> <snip>
>>
>> Chuck
>>
>> _______________________________________________
>>
>> SciPy-Dev mailing list
>> SciPy-Dev@scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev@scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
I do appreciate the work that various people put into this project but
this sort of illustrates the frustration that some of us mere users
have with numpy and scipy. One hand you appear to want to change the
numpy governance to being more open and community driven yet this
thread does reflects the opposite.

Sure I think that bugs should be fixed such as the way Fernando
described. But adding or removing features need a more community-based
approach than a single developer.  Given the silly bugs due not
testing supported Python versions and platforms, which seem to
regularly occur during release time, there is strong need for
community involvement. One of the advantages of this whole distributed
approach is that different trees can be merged at specific times like
release dates (somewhat like the Linux kernel does). At least this
would find and force the fixing of those silly bugs otherwise that
code would not go in at that time.

The other advantage is that people could be encouraged to do code
review and perhaps become contributors when they know that work is
appreciated - Welcome abroad Denis!

Bruce


More information about the SciPy-Dev mailing list