On 27 May 2010 01:22, Charles R Harris <charlesr.harris@gmail.com> wrote:
>
>
> On Wed, May 26, 2010 at 9:49 PM, Jarrod Millman <millman@berkeley.edu>
> wrote:
>>
>> On Wed, May 26, 2010 at 8:08 PM, Matthew Brett <matthew.brett@gmail.com>
>> wrote:
>> > That's the model we've gone for in nipy and ipython too.  We wrote it
>> > up in a workflow doc project.  Here are the example docs giving the
>> > git workflow for ipython:
>> >
>> > https://cirl.berkeley.edu/mb312/gitwash/
>> >
>> > and in particular:
>> >
>> > https://cirl.berkeley.edu/mb312/gitwash/development_workflow.html
>>
>> I would highly recommend using this workflow.  Ideally, we should use
>> the same git workflow for all the scipy-related projects.  That way
>> developers can switch between projects without having to switch
>> workflows.  The model that Matthew and Fernando developed for nipy and
>> ipython seem like a very reasonable place to start.
>> __
>
> I wouldn't. Who is going to be the gate keeper and pull the stuff? No
> vacations for him/her, on 24 hour call, yes? They might as well run a dairy.
> And do we really want all pull requests cross-posted to the list? Linus
> works full time as gatekeeper for Linux and gets paid for the effort. I
> think a central repository model would work better for us.

I don't think this is as big a problem as it sounds. If the gatekeeper
takes a week-long vacation, so what? People keep working on their
changes independently and they can get merged when the gatekeeper gets
around to it. If they want to accelerate the ultimate merging they can
pull the central repository into their own and resolve all conflicts,
so that the pull into the central repository goes smoothly. If the
gatekeeper's away and the users want to swap patches, well, they just
pull from each other's public git repositories.