Re: Google Summer of Code 2013 (GSoC13)

Ramkumar Ramachandra [off-list ref] writes:

[corrected David Barr's email address]

Jeff King wrote:

quoted

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