Charles R Harris
Tue Jun 1 08:50:30 CDT 2010
On Tue, Jun 1, 2010 at 2:43 AM, Travis Oliphant <email@example.com>wrote:
> On Jun 1, 2010, at 3:12 AM, firstname.lastname@example.org wrote:
> On Tue, Jun 1, 2010 at 12:54 AM, Travis Oliphant <email@example.com>
> On May 31, 2010, at 9:16 AM, firstname.lastname@example.org wrote:
> Since Travis seems to want to take back control of scipy.stats, I am
> considering my role as inofficial maintainer as ended.
> Obviously I've offended you. That has never been my intent. I apologize
> if my enthusiasm for getting some changes that I wanted to see into SciPy
> stepped on an area you felt ownership of. I do not mind if people add
> changes to code that I've written and I assume that others feel the same.
> That has always been the development mode of SciPy. We clearly have
> different development styles. I think we can find a way to work together.
> I think the move to github will help.
> I did not understand that you felt such ownership of scipy.stats. I have
> certainly appreciated your input.
> I do like a more "free-wheeling" style to code development than one that is
> bogged down with "rules" and "procedures". This clearly is not your
> style. For me, it comes down to time to spend. I love working on SciPy
> and NumPy. I don't have a lot of time to do it. When I see quick
> changes I can make that add value I like to be able to do it. I think we
> both want the same thing while we may disagree about the best way to get
> In my mind, discussion doesn't end when a check-in is made --- it just
> begins. You should never interpret my checking something in as the final
> word. We clearly have a different view of "trunk"
> I certainly don't want my approach to open source development to offend
> others or chase them away. If I check in something you don't like, then
> tell me and let's talk about it. If you need to vent and call me names, a
> private email to me or others can go a long way.
> What do we need to do to keep you around? Is there specifically something
> you didn't like about my recent check-ins?
> In this case, the features added were not terribly extensive. The current
> unit tests helped ferret out major problems. Yes, I could write more tests
> and documentation, and you have been a model of writing tests and
> documentation. I have been particularly impressed by the amount of quality
> documentation you have written.
> While you seem to dismiss the episode as problematic, I actually think
> curve_fit was a good example of how something very positive can emerge
> quickly when people are open and willing to work together.
> While formal, strict test-driven development is easy to point to for
> salvation -- it does have its costs. I've always used informal test-driven
> development. Just because I don't *always* add formal unit tests for every
> piece of code written does not mean the code that is currently in SciPy is
> un-tested and useless. Such an approach leaves me open to criticism, which
> I acknowledge. But, I think there have been far too many dismissive
> comments about the state of the code.
> I would argue that the problem with scipy.stats does not lie mainly in
> distributions.py or the lack of test-driven-development --- but in the lack
> of certain easy to use features. Quality code comes out of people who
> care --- not out of procedure.
> I think you are someone who cares and your code reflects that. We would
> all benefit from your staying part of the main development.
> (not answering inline to keep thoughts together)
> I think the main disagreements are about the quality control of the
> trunk and whether scipy development is a community effort or not.
> I certainly think scipy development is a community effort. I'm very sorry
> for making you feel "dumped" on. That has never been my intent. I was
> simply hoping to contribute a little where I could.
> As Skipper described, in statsmodels almost all development occurs in
> the sandbox and in branches, and it is only included in the "official"
> core of statsmodels after it has been verified and tests have been
> added. sandbox code is everything from first draft version to almost
> finished code.
> And one of Skippers task in his gsoc is to clean out the sandbox.
> Once it is in trunk (core) any further refactoring follows very strict
> This has not been SciPy's process. I can understand people may want it to
> become SciPy's process, but it has not been. There are dangers of this
> process --- there is a reason that the mantra of "release early and release
> often". It can also prevent progress when you are dealing with people's
> spare time because all of that process takes time and man-power and effort.
> There is some value in it, I'm just not sure the extent of that value in
> contrast to other uses of that time.
Numpy/Scipy has changed from the days when there were just a few folks
involved and the urgent need was to get some code, any code, out there. I'm
sure many projects start that way because in beginning the idea is the
important thing, the perfection of the implementation not so much. But as
things progress and more people use the code, correctness becomes important.
The numpy/numeric C code itself shows this process, with the early code
quality being what I would classify as "undergraduate" C. That doesn't mean
Numeric wasn't useful, obviously many people found it so or we wouldn't be
here, but it does mean that the code wasn't easy to maintain or understand.
Now the basic ideas have been worked out and the originators have moved on
while at the same time the code has become more widely used, so the need
becomes maintenance, correctness, distribution, and attracting the people to
do those things. That requires a different sort of process.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev