Re: Google Summer of Code 2013 (GSoC13)

[Thomas Rast <trast@inf.ethz.ch>]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> [corrected David Barr's email address]
>
> Jeff King wrote:
>> And I do not want to blame the students here (some of whom are on the cc
>> list :) ). They are certainly under no obligation to stick around after
>> GSoC ends, and I know they have many demands on their time. But I am
>> also thinking about what Git wants to get out of GSoC (and to my mind,
>> the most important thing is contributors).
>>
>> As far as merged code, I think part of the problem is that git is fairly
>> mature at this point. The most interesting projects are of a bigger
>> scope than a student with no experience in the code base can do in a
>> summer project. Maybe that means we need to do a better job of breaking
>> projects down into reasonably sized sub-components. Or maybe it means
>> the project is hitting a point of diminishing returns for GSoC. I don't
>> know.
>
> I'll be frank here.  I think the main reason for a student to stick
> around is to see more of his code hit `master`.  I think it is
> absolutely essential to get students constantly post iteration after
> iteration on the list. It would be nice to get them connected with 2~3
> people in the community who will follow their progress and pitch in
> everytime they post an iteration.  It might also make sense to stage
> their work in the main tree (a gsoc/ namespace?), so we can just
> checkout to their branch to demo what they've done.

I agree, but I think there's an additional component.  Consider the 'log
-L' feature.  It's fairly workable, and I merge it in my own builds and
use it, but there were and are two main issues:

* The initial work by Bo was not in shape to be included, mostly because
  the code was too convoluted in the parts that process line ranges.

* The last version I posted was held up because there's _in principle_ a
  better way to do things, but it requires major refactorings of
  existing code.

I'm not going to try to discuss away the first one; it's also a failure
of myself as mentor.  However, as far as incomplete work goes, I think
the latter item is fairly symptomatic.  We underestimate the amount of
work required to polish and reroll a submission that a student would
deem "sufficiently working for inclusion", fixes to be done later.

So I agree with your suggestion:

> What's the harm of including something estimated to take 80% of a
> summer?

Maybe even less than 80%.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch