Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html