Re: Google Summer of Code 2013 (GSoC13)

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Feb 18, 2013, 19:34 UTC
Message-ID: <20130218193424.GC3234@elie.Belkin>
In-Reply-To: <20130218174239.GB22832@sigill.intra.peff.net>

Hi,

Jeff King wrote:

Show 7 quoted lines

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

I think that if we can commit enough time to mentor well it's worthwhile. Even such a negative result is useful, since it can teach us how good or poor we are at bringing new contributors in and what parts of that process need more work.

That said, I won't have time to mentor a project on my own. It takes a lot of time (or luck, to get the student that doesn't need mentoring). I'd be happy to help on a project with 1 or 2 co-mentors.

Some potential projects (unfiltered --- please take them with a grain of salt):

 - cross-compilable git

 - incorporation of the cgit web interface, or formalizing a subset of
   libgit.a to export as a stable library to it

 - merging the gitweb-caching fork

 - moving forward on a project that was the subject of a previous
   gsoc project: line-level logging, "rebase --interactive" on top of
   sequencer, usable svn remote helper

 - collapsable --first-parent history in gitk
   http://bugs.debian.org/600001

 - drag-and-drop cherry-pick in gitk

 - a sub-library of code shared with libgit2 (might be hard because
   our notions of strings are different :().

 - assimilating the distro builds: "make deb-pkg", "make rpm-pkg",
   etc along the same lines as the linux kernel's script/package/,
   to help people get recent git installed when they want it

 - "please cherry-pick this before testing that" notes for less
   scary bisecting

 - collaborative notes editing: fix the default notes refspec,
   make sure the "notes pull" workflow works well and is documented
   well, offer an easy way to hide private notes after the fact
   without disrupting public history

Hope that helps, Jonathan