Re: Google Summer of Code 2013 (GSoC13)

From: Carlos Martín Nieto <cmn@delego.de>
Date: Feb 21, 2013, 14:29 UTC
Message-ID: <87wqu1zqn4.fsf@centaur.cmartin.tk>
In-Reply-To: <51252877.5000808@schu.io>

Michael Schubert <schu@schu.io> writes:

Show 23 quoted lines

> 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