Re: Google Summer of Code 2013 (GSoC13)

From: Thomas Rast <trast@inf.ethz.ch>
Date: Feb 18, 2013, 19:45 UTC
Message-ID: <87fw0txv6r.fsf@pctrast.inf.ethz.ch>
In-Reply-To: <CALkWK0nDEwgDwnVktmM8abv3ZgQmJCOm8LBe25UKR485PZMPfA@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 25 quoted lines

> [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