[SciPy-Dev] Repository for GSoC project

[Ralf Gommers]

On Mon, May 25, 2015 at 11:10 PM, Jaime Fernández del Río <
jaime.frio at gmail.com> wrote:

> On Mon, May 25, 2015 at 1:10 PM, <josef.pktd at gmail.com> wrote:
>
>>
>>
>> On Mon, May 25, 2015 at 3:37 PM, Jaime Fernández del Río <
>> jaime.frio at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> This year I am mentoring Aman for one of the GSoC projects we have
>>> underway, "Rewriting ndimage in Cython." By its very nature it doesn't
>>> conform very well to the "many small pull requests" model: from the point
>>> of view of scipy, things are going to be broken up until almost the very
>>> last commit. I am not sure what the best way to set up a collaborative code
>>> development environment would be, and so am asking for the collective
>>> wisdom to help guide us.
>>>
>>> Aman could simply create one ginormous pull request that will grow, and
>>> grow, and not be merged until everything was ready. I don't like this idea
>>> too much, as it is going to eventually be a confusing mess, and I think it
>>> would also make it difficult for others than Aman (that would mostly be me)
>>> to contribute code.
>>>
>>
This is the worst option I think; it's very hard to keep track of what's
already reviewed in an open PR.


>
>>> I think we could also use a branch, either on my fork of scipy or on
>>> Aman's, as the repository on which development would happen, and against
>>> which PRs would be created, and once completed send a single PR to the main
>>> scipy repo. This may work, but I don't like it much either.
>>>
>>> What probably makes more sense is to create a new branch **in the main
>>> scipy repository**, and have PRs sent and merged against that branch, which
>>> would eventually be merged with master upon completion. NumPy seems to have
>>> a couple such experimental branches ('with_maskna' and
>>> 'enable_separate_by_default'), although there is none in SciPy that I see.
>>> This would also allow us to keep the project in a controlled environment,
>>> even if by the end of the summer not every single bit of ndimage has been
>>> ported.
>>>
>>
I'm not a fan of topic branches in the scipy repo, but given the nature of
the rewrite it's probably the best alternative. So fine with me.


>>> If this third path is really the preferred way of doing things, I could
>>> probably set things up myself (Ralf gave me commit rights when I became a
>>> mentor for this project),
>>>
>>
That's what I get for forgetting to send the announcement in time:) Not
just me by the way - decided on by all active core devs.


> but I'd like to hear what others think, before abusing my powers.
>>>
>>
>>
>>
>> I don't see much difference between options two and three for working
>> with github since it''s easy to create and merge pull requests across forks.
>>
>> One consideration is whether you want to trigger the TravisCI runs, which
>> I guess would be automatic with a branch in the main scipy repo.
>>
>> Another consideration is whether this triggers a large amount of
>> notifications for scipy developers that are subscribed to changes, PRs and
>> issues. (and if it's easy for me to filter those out visually in gmail)
>>
>
> I understand the concern: I am myself often baffled by the amount of
> e-mail from the scipy repo that I delete without reading. That said, what
> you sign up for when you sign up to the SciPy github repo is to receive all
> notifications related to that repo, which does include ndimage... And I
> don't think that the fact that these changes will be part of GSoC warrants
> treating them in a special way. Also, given the volume of mail that SciPy
> already generates, this will probably be lost like tears in the rain
> anyway...
>
> As a more general thing, it may make sense to come up with three letter
> acronyms for each of the scipy submodules, and ask that PRs identify the
> submodule(s) they affect as part of the title. I certainly have no problem
> in requiring that every PR in this project has `[NDI]` for `ndimage` as
> part of the description, e.g. "[NDI] ENH: blah, blah, blah..."
>

No reason not to type the module name out in full, and I'd like to keep the
standard prefixes at the front. So I'd be more in favor of "ENH: ndimage:
...". I actually already do that sometimes.

Ralf



> Jaime
>
>
>>
>> In statsmodels all the extra branches in the main repo are stale or
>> stalled and are waiting for someone to pick up. Actual development is in
>> developer forks.
>>
>> (I'm not involved enough in scipy development to have an opinion.)
>>
>> Josef
>>
>>
>>>
>>> Thanks!
>>>
>>> Jaime
>>>
>>> --
>>> (\__/)
>>> ( O.o)
>>> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus
>>> planes de dominación mundial.
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
>
> --
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
> de dominación mundial.
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150525/d0f061f6/attachment.html>