Re: Google Summer of Code 2013 (GSoC13)

[cmn@delego.de (Carlos Martín Nieto)]

Michael Schubert <schu@schu.io> writes:

> On 02/18/2013 06:42 PM, Jeff King wrote:
>> 
>> I will do it again, if people feel strongly about Git being a part of
>> it. However, I have gotten a little soured on the GSoC experience. Not
>> because of anything Google has done; it's a good idea, and I think they
>> do a fine of administering the program. But I have noticed that the work
>> that comes out of GSoC the last few years has quite often not been
>> merged, or not made a big impact in the codebase, and nor have the
>> participants necessarily stuck around.
>> 
>> 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).
>
> Speaking of libgit2:
>
> Git provided the libgit2 project with a slot each of the last three GSOC.
> The contributions made by the former students (Disclaimer: one of them
> speaking) have been quite important for libgit2 and all three students
> are still involved. Each project was an important push towards building
> a new, feature complete Git library.

Right, speaking of libgit2. GSoC has been very successful (as Michael,
I'm also somewhat biased) for libgit2. This happens outside of the git
ML so it probably hasn't gotten as much visibility here.

I believe it's partly because there were still larger parts where most
of the work was technical and the goal was quite clear, as git had
already set the standard and expectations and the decisions had to be
mostly about how to implement it in a way that makes sense for a
library, rather than it living inside of git, which is not always easy,
but you can experiment with different uses of it.

It's also possible that part of the success was the fact that we were
already acquainted with the "release often and early" policy, as we'd
been involved with FLOSS for a while already.

The current gaping hole in libgit2 is the lack of merge support, which
is the last hurdle to a stable 1.0 release. There is already some work
by Edward Thomson that needs to be reviewed and merged. I'm not sure
that there's enough for a whole summer there, but you could throw in the
review and merge of another missing feature, which is making the
reference storage generic, as it currently only supports the
git-compatible file-based one. There's other nice-to-have things like
thin-pack support that you could use to fill up a summer, though I'm not
sure that goes with the spirit of the programme.

Something else that needs love is Git for Windows. I believe both git
and libgit2 would benefit a lot from a project to take some parts of git
that are implemented in a scripting language and port them to use
libgit2. As Git for Windows needs to ship a ton of dependencies anyway,
using a pre-1.0 library wouldn't be an issue and it can be used to
experiment with an eventual porting of git to be one user of libgit2
rather than a completely different implementation. The more immediate
benefit for Git for Windows would be less reliance on languages that are
awkward to use on Windows and need their own environment. Mentoring from
the libgit2 probably wouldn't be much of an issue to organise, though
I'm not sure if the GfW team would have time for the part that involves
its peculiarities.

So there's a couple of projects that could be done with some realistic
chance of being merged upstream, as they'd be technical, as long as we
do tell the student to send small units of work to be reviewed often.

Cheers,
   cmn