Google Summer of Code 2008

I have just read (via Linux Today news[*1*]) that GSoC 2008 initiative starts early. Applications for organizations open March 3 and close March 12. Git development community participated in GSoC 2007 with two projects accepted[*2*]: builtinification and libification. What do you think about their results for git? What do you think about participating in this year GSoC?

Cc: Shawn Pearce, who was promary contact for GSoC 2007.

Footnotes: ========== [1] http://blog.internetnews.com/skerner/2008/02/google-summer-of-code-2008-alr.html [2] http://git.or.cz/gitwiki/SoC2007Projects

Hi,

On Tue, 26 Feb 2008, Jakub Narebski wrote:

I think that GSoC2007 was quite nice for us. And with what we learnt, we would do even better in 2008.

However, I simply do not have the time to serve as primary contact. I am willing to be mentor again, though.

As for projects, I imagine that Gitorrent, further builtinification and Windows support would be good candidates.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

I agree.  Unfortunately though it seems only 3 of us out of 855
current subscribers to the git mailing list have anything to say
on the subject in the past couple of days. :-\
 

I'd be willing to do it again, as well as mentor a student.  I found it
very interesting last year.
 

Yea, Gitorrent would be cool. Especially since send-pack is somewhat heavy on the server's resources and there are some very popular projects offered in git format (hello Linux kernel!).

I'd love to see new features added to git-gui, but I'm being selfish. Ditto with jgit and egit, though I think Robin has done a stellar job with them thus far. I can still want them to grow.

pack v4 (or maybe v5?! a student could have better ideas then we have thus far come up with) would also be interesting.

My list could probably go on for a bit.

"Shawn O. Pearce" <spearce@spearce.org> writes:

[snip]

Just as a suggested project, it seems that a continuation of the efforts on libgit-thin would be very useful.

Hi,

On Thu, 28 Feb 2008, Jeremy Maitin-Shepard wrote:

It would be nice if you added that to the Wiki page, and maybe added yourself as mentor?

Ciao, Dscho

Hi,

On Thu, 28 Feb 2008, Shawn O. Pearce wrote:

Yes, it is sad. Even if now 4 out of 855 current subscribers said something.

Thanks!

Why? I see that we had many ideas, less student applications, and even less accepted.

So let's throw ideas out there!

Robin, how about it?

That would need a student who is already familiar with Git, though. A Git newbie has no chance to learn everything necessary (including the style of the community) in 3 months _and_ finish the project.

Do go ahead!  I started the page

	http://git.or.cz/gitwiki/SoC2008Ideas

which is utterly incomplete. I just took the ideas of 2007 that I am still interested in, and removed other people from the Mentor list, because I do not want to force them. So please, if you are interested in mentoring one of the existing projects, just add yourself.

And of course add all those cool projects you have in mind.

Shawn, do we have to do the same again, as on this page?

	http://git.or.cz/gitwiki/Soc2007Application

Ciao, Dscho

On Thu, 28 Feb 2008, Johannes Schindelin wrote:

By the way, when looking at 2007 GSoC ideas one can see that some of them got implemented already outside of GSoC, and are no longer valid; well, perhaps as "improve <sth>" ideas.

Subproject/submodule support got implemented, Mozilla has decided to use Mecurial instead of Git (but there are other large-scale imports: OpenOffice.org, GCC) and cvs2svn supports fast-import output which means export to git, gitattributes support got much extended.

I have some interesting ideas for GSoC, but unfortunately none (with perhaps single exception) that I could mentor. So I think I'd list them here for now, and later I'd add it to SoC2008Ideas page.

Here they are.

First, a few ideas which got partially implemented already, or are implemented and need improvements. I don't know if current contributors would want to be mentors, or would they want to submit their work under GSoC as participants.

* Lazy clone / remote alternates

  The idea here is to be able to remotely access objects from a network
  based object server, as neededm rather than having them all local.

  Goal: A working lazy clone prototype implementation that could be
  considered for inclusion, in a nice series of commits (separate
  branch/fork)
  Language: C
  Suggested mentor: Jan Holesovsky, who submitted proof-of-concept
  patch for lazy clone

* Partial (subtree) checkout, or its generalization: sparse checkout

  The idea is to checkout for example only Documentation subdirectory,
  work on it, but commit full tree. Some workflows may be better suited
  to this type of usage than using submodules. Optionally should include
  partial clone (not needed objects not in repository).

  Goal: A working partial checkout prototype implementation, with
  technical documentation.
  Language: C
  Suggested mentors: 
    gitzilla (sent proposal), 
    Nguyen Thai Ngoc Duy (pclouds), proposed to implements it

* Gitweb caching

  Implementing very smart caching in gitweb, to avoid the thundering
  herd problem on kernel.org whenever a repository gets updated, or at
  least support for caching engines in the form of generating proper
  Last-Modified: and ETag: headers, and responding to If-Modified-Since:
  and If-None-Match: requests, cheaply. 

  Perhaps becoming the gitweb maintainer could come of it, or at least
  the gitweb admin for kernel.org (sorely needed).

  Goal: At minimum, port kernel.org's caching to mainline (git's) gitweb
  Language: Perl, HTML, perhaps JavaScript
  Suggested mentors:
    John 'Warthog9' Hawley (wrote caching for kernel.org's gitweb)
    Petr Baudis (repo.or.cz admin)
    Lars Hjemli (cgit author, git web interface in C, with caching)
    Jakub Narebski (gitweb contributor)

Then, a few ideas which were proposed for GSoC 2007, but never implemented, and wasn't mentioned in this thread or on wiki for GSoC 2008 yet

* Git / Subversion Interoperability

  The idea here is implement something in Git that speaks the Subversion
  protocol on the wire, but uses Git as the backend storage. (This would
  be like the existing git-cvsserver.)

  There are two potential approaches:

   1. git-svnserver
   2. write a backend for Subversion

  Goal: To be able to access git repository, at minimum read-only, from
  a Subversion client, at least svn CLI.
  Language: Open for proposal.
  Suggested mentors: 
    Eric Wong (git-svn author)
    Matthias Urlichs (git-svnimport author)
  Notes: I don't think we could pass it as Subversion SoC project, but
  I guess that we could ask for co-mentor for the Subversion protocol,
  or Subversion backend part of this task.

I'd send other ideas (including new ones, like translating svn:externals into git submodules in git-svn; or making git mode for Emacs have all features of tig, git-gui and gitk; or improving shallow clone support) in a later post.

A few things changes for us: we have participated in GSoC 2007; we need to find backup organization administrator (was: Martin Langhoff for GSoC2007), list of mentors would change most probably.

As far as I've checked the application form for organizations didn't change...

On Fri, 29 Feb 2008, Jakub Narebski wrote:

FWIW: I have a partially implemented python git-svnserver that speaks the 
svn:// protocol ... so far I can checkout from a git repos using the svn 
client, and not much else.  It's been on the backburner for a while, but I 
had recently thought about revisiting it - but getting someone else to do 
the implementation works too ;)

Hi,

On Fri, 29 Feb 2008, Julian Phillips wrote:

How about publishing it, so other people can take up the ball?

Ciao, Dscho

On Fri, 29 Feb 2008, Johannes Schindelin wrote:

It did work very well for the builtin fetch, didn't it? (thanks Daniel)

Progress so far can be found at:

http://git.q42.co.uk/w/git_svn_server.git

Jakub Narebski wrote:

Great - I've put these all up on the wiki along with GitTorrent, and noted Julian Phillips as a possible mentor for the git-svnserver. I'll again point out that I wrote a plan for this effort at http://utsl.gen.nz/git/git-svnserver.txt - though that may be becoming more and more irrelevant.

Funnily enough, I'm actually a possible /student/ this year - I'm studying full-time this year - not in Computer Science, but hey that's not a requirement ;-), and perhaps finishing my GitTorrent implementation in my breaks would be a nice way to earn US$5k. It would be contrary to all of the "goals" of the programme¹, bar the first. I'd have to get the work done on a slightly different schedule because of the hemispherical term difference... but possible. Would this be an abuse of the programme. I leave the moral question open to the list; I can easily find paid contracting work over the time anyway. But this would be *fun* :-)

Sam.

¹ http://code.google.com/soc/2008/faqs.html#0.1_goals

Hi,

On Sat, 1 Mar 2008, Sam Vilain wrote:

You have my vote. If this works out, I will be your mentor. As you know, I will not be easy to work with, but the outcome will be pleasing to you _and_ me.

I think GitTorrent is a really interesting project. And since I do not have time to do it myself, I would really appreciate this to be a GSoC project, preferably a successful one (which is the reason I am willing to mentor it).

Ciao, Dscho

Johannes Schindelin wrote:

Excellent, well that was going to be the next question - who would be the mentor, and what would they do?

I guess I could re-work this RFP to be a proposal to complete it;

  http://utsl.gen.nz/git/gittorrent-rfp.txt

So far, the first two milestones on the plan are basically nailed, so that's something of a head start. The test script fires up two nodes that connect to each other, sends a choke message and then shuts down. I'm quite happy with the stack being used (Moose - which is CLOS for Perl, and Coro - coroutines, similar to stackless python). How about I brush that up and we can take this discussion off-list.

Sam.

On Fri, 29 Feb 2008, Jakub Narebski wrote:

And here they are.

* GNU Emacs git GUI

  Make git mode for Emacs full featured git GUI, and not only commit
  tool, following ideas of PCL-CVS... and its limitation. I guess that
  DVC (http://download.gna.org/dvc) git mode is one thing to examine
  searching for features to implement, but from what I have read in
  documentation it is quite a but GNU Arch centric. Other git GUIs, like
  git-gui, gitk, qgit, tig could also be inspiration for features.

  Goal: Allow creating and switching branches, examining history,
  merging, fetching etc. from withing Emacs. Should include modes for
  git config file forma and format-patch patches.

  Language: Emacs Lisp
  Suggested mentors:
    Alexandre Julliard
    David Kagedal

* git-svn and submodules (and other improvements)

  Make git-svn translate svn:externals (full kind) submodules into git
  submodules. This might require improvements to submodule support in
  git. Other improvements include proper dealing with miscelaneus
  Subversion properties (translating them into .gitignore
  and .gitattributes entries).

  Goal: Succesfull two-way interaction with Subversion repository using
  svn: externals for submodules.

  Language: Perl
  Suggested mentors:
    Eric Wong (git-svn author)
    Shawn O. Pearce
    Johannes Schindelin

* Shallow clone improvements

  IIRC the interaction with shallow clone is a bit limited. Lift those
  limitations, allowing for example to push from shallow to full clone.

  Goal: Push from shallow clone to full clone, or other shallow clone.
  Language: C
  Suggested mentors: Johannes Schindelin

* blame Merge Strategy

  A new merge strategy "merge-blame". It should take advantage of code
  (fragment) movement and copying detection in git blame, correctly
  applying change to correct place if code was moved (e.g. reorganizing
  code) or moving fragment into another file.

  This strategy should probably be a function within merge-recursive
  that is activated only when merge-recursive is invoked as merge-blame
  (or some perhaps some better name). Further it probably should only be
  used when a file fails to be merged cleanly, as a "last resort before
  asking the developer to do it for me" sort of trick. Rationale here is
  the blame computation is non-trivial and will take some CPU time, so
  we want to avoid that in the common cases of non-moved code.

  Goal: Demonstrate a working merge-blame that can fairly accurately
  merge changes made to moved code segments.

  Language: probably C
  Suggested mentors: unknown

Jakub Narebski <jnareb@gmail.com> writes:

The documentation is, but the tool isn't. Actually, DVC started as "Xtla", which was _only_ a GNU Arch interface. The tool evolved a lot since then, but the documentation is totally outdated :-(.

[Cc list culled]

On Sun, 2 Mar 2008, Matthieu Moy wrote:

I wanted then tro try DVC out, but when comiling it I get the following error message:

  Cannot open load file: dvc-site
  make[1]: *** [clean-some] Error 255
  make[1]: Leaving directory `/tmp/dvc-snapshot/++build/lisp'
  make: *** [dvc] Error 2

GNU Emacs 21.4.1, after running autoconf and ./configure. Today's snapshot.

Jakub Narebski <jnareb@gmail.com> writes:

Best is to try the DVC's mailing list. I'm CC-ing it (it's a moderated list for non-subscribers, your messages will take some time).

I used to be an active DVC contributor, but by lack of time, I didn't follow closely recent development. I'm not sure Emacs 21 is still supported (and at least, it's not well tested since most developers run Emacs 22 themselves).

On Sat, Mar 1, 2008 at 1:04 AM, Jakub Narebski <jnareb@gmail.com> wrote:

Unfortunately, this year I'm seriously swamped, as I'll probably be mentoring a few GSoC projects for Moodle and OLPC (due to http://lists.laptop.org/pipermail/devel/2008-February/011314.html ). Within OLPC I will be using bits and pieces of git, so I may come up woth something git related.

cheers,

martin

Hi,

On Mon, 3 Mar 2008, Martin Langhoff wrote:

Okay, if all else fails, I volunteer to be the backup admin.

Ciao, Dscho

Hello,

On Thu, Feb 28, 2008 at 7:36 AM, Shawn O. Pearce <spearce@spearce.org> wrote:

I will take this opportunity to add a few comments and promote a page. To help improve chances of success for such a project, perhaps a "community" edition of the protocol is in order. I have been planning (and still are) to do a review of the protocol specification with input from the mailing list. Basically, I am thinking to break the current RFC document into self-contained chunks: a formal introduction + goals, meta file and tracker part, and finally repository serialization and peer wire.

In preparation, I started to populate pages at:

  http://gittorrent.googlecode.com/

If there is interest I will try to find time to restart this process.