[SciPy-Dev] cKDTree

[Sylvain Corlay]

Hey,

On Sat, Sep 10, 2016 at 2:34 PM, Pauli Virtanen <pav at iki.fi> wrote:

> Hi,
>
> Thu, 08 Sep 2016 23:12:54 +0200, Sylvain Corlay kirjoitti:
> [clip]
> > On the subject of the use of a faster flavor of KdTree as I was
> > proposing, I was only gauging interest. The long discussion on DE on
> > this specific thread is mostly coincidental. My main goal was to use it
> > as an example for the question of the scope - also to ask about the
> > "big split" idea. If there was to be a split, a potential
> > scipy-incubator organization with proposals for inclusion as
> > scipy subprojects would make sense then... If there was to be a split,
> > a potential scipy-incubator organization with proposals for inclusion
> > as scipy subprojects would make sense then...
>
> Now that we're still derailed:
>
> Several years back, there was a scipy.sandbox package which was nominally
> aligned with things intended for inclusion, but it was scrapped in the
> end: http://blog.jarrodmillman.com/2007/12/end-of-scipy-sandbox.html
> Some of these did end up as scipy subpackages, but many also were
> scrapped or turned up into separate projects.
>
> This was of course before Git/Github --- nowadays I think the role is
> mainly served by PRs, and for more complicated stuff, separate ad-hoc
> repositories plus issue tickets. Of course, scipy.sandbox had also
> overlap with completely separate projects.
>
> With the "staging area", the main question is that is the amount of
> significant new features proposed such that there should be a separate
> "staging area", aside from PRs etc.  Or, would such staging area
> encourage their creation?  Or would it be useful for creating completely
> new projects?  It's not really clear to me that this is the case.
>
> In a more decentralized "big split" approach, "Scipy" probably would
> mainly stand as some sort an umbrella organization for more or less
> separate projects.  Does such central authority need to exist, apart from
> the sense of maintaining the specific projects?  Is it better in some
> sense than the completely decentralized scikit approach?
>

The benefits / reasons of a split would be the same as usual: managing
growth by a separation of concerns and focus, with lines of division would
be defined with both technological and scientific criterions. Keeping
things under a single umbrella would show the intention of keeping
consistency between the different components on certain aspects.
Experiments that imply significant changes like a new type of language
bindings would have less implications for packaging since they would remain
separate.

Cheers,

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20160910/e416038c/attachment.html>