Welcome to Git's GSoC 2008!

Congratulations, and welcome to the Git community!

By now I hope you are aware that your project proposal has been selected by the Git community, and will be funded thanks to the extremely generous folks at Google.

This year Git was fortunate enough to receive funding for 6 students, and we are looking forward to the successful completion of the following interesting projects:

  GitTorrent
      Student: Joshua Roys
      Mentor:  Sam Vilain

      Josh and Sam will be working to implement native git object
      transport via a peer-to-peer system, potentially allowing
      popular projects such as the linux kernel to be available
      via more servers than just git.kernel.org.

  git-statistics
      Student: Sverre Rabbelier
      Mentor:  David Symonds

      Sverre and David are looking to mine the commit history of
      a project and identify "good" changes from "bad" changes.
      Such information may help maintainers to better judge the
      risk associated with new changes, and help new contributers
      to more quickly locate individuals who are experienced in
      a particular section of code (e.g. automatically identify
      module maintainers).
    
  Gitweb caching
      Student: Lea Wiemann
      Mentor:  John 'warthog' Hawley

      Lea and John will be working to port the caching gitweb fork
      that runs on kernel.org back into the main tree, as well as
      implementing even more improved caching for really large sites
      like kernel.org, repo.or.cz, or anyone else using gitweb for
      a large number of repositories and users.
    
  Eclipse plugin push support
      Student: Marek Zawirski
      Mentor:  Shawn O. Pearce

      Marek and myself will be working to implement pack generation
      in jgit, allowing the 100% native Java implementation of Git
      to create pack files locally, as well as upload pack files to
      a remote repository over the native Git transport.  Marek is
      also looking forward to improving some of the user interface
      aspects of the Eclipse Git team provider plugin.
    
  git-merge builtin
      Student: Miklos Vajna
      Mentor:  Johannes Schindelin

      Miklos and Dscho will be porting the git-merge shell script
      to C, permitting it to make use of builtin functions like
      merge base computation, and making the program overall more
      portable to non-POSIX systems.  Porting some of the popular
      merge strategies (e.g. git-merge-ours) will also be done as
      time permits.
    
  git-sequencer
      Student: Stephan Beyer
      Mentor:  Christian Couder, Daniel Barkalow

      Stephan, Christian and Daniel will be working to port the
      current "git rebase --interactive" to C, as well as create
      a general "commit sequencer" that can be used as the backing
      implementation for "git-am", all three forms of "git-rebase",
      and possibly implement an "interactive rebase GUI" within
      git-gui and/or gitk.

Student projects will be worked on roughly full time (~40 hours/week) between May 26th and August 18th.

Right now you should spend some time talking to your mentor(s), so you can both get to know each other better. Here's a rough idea of some of the things you should be trying to work on with your mentor over the next several weeks:

 - Get a copy of Git installed, and become familiar enough with
   it that you can make changes and commit them.

 - Clone the project you will be working to improve.

   - Can you compile it?
   - Can you run your compiled version?
   - Can you make a silly modification (make it say "hello world!")
     and see that modification when you test it?

 - Discuss where you will be publishing your work.  Publish the
   base (unmodified) code to make sure you can publish your own
   work later.

   I highly recommend creating a repository on repo.or.cz.  It is
   free, and for many of you the upstream project (git.git or
   egit.git) is already hosted there, so you just create a fork
   from it.

 - Start dicussing with your mentor your timeline and goals.

   Yes, you covered this in your proposal.  But now that its actually
   something you will be working on this summer it will really help
   both you and your mentor if you can work out a more detailed
   plan of the tasks ahead of you.

 - Discuss your personal schedule(s) with your mentor(s)/student(s).

   Will you be planning to be offline for any period of time?
   Taking a summer vacation/holiday for a week?  Now would be a
   good time to share this information, so everyone knows what to
   expect this summer.

 - Consider reviewing the GPL if you have not read it.

   Nearly all Git related code is covered by the GNU Public License.
   Individual authors (that's you) retain the copyright on works
   they create.  (egit/jgit is a special case, I'll take it up with
   Marek on another thread.)

 - Ask you mentor to introduce you around.

   You and your mentor are not working in a vacuum.  Hundreds of
   people have contributed to Git over the years and there is
   a wealth of knowledge in the community that you can leverage
   to your benefit.  Work with your mentor to develop additional
   contacts with other contributors who are knowledgable in the
   area of your project.  Don't hesistate to ask these folks for
   help when you get stuck, especially if your mentor is unable to
   answer you immediately.

We realize you are still taking classes, and have project deadlines, homework and exams to still worry about. But now that you are accepted into GSoC its also time to start setting aside a few hours a week to plan out your summer, so you can make the most of this opportunity.

We are excited to have you join us, and are really looking forward to these projects!

Final note: I am your friendly organization administrator. If you have any questions that your mentor can't answer, etc., please email me. I'm here to help both the student and the mentor make the most of this summer.

This year Google Summer of Code really grew as a program. Over 7,100 applications were submitted, almost 1,000 more than last year. Students applied from more than 1300 colleges and universities, in more than 98 countries[*1*].

This year Google offered funding for 1125 students. This is more than $5.6 million USD given freely to 177 open source projects and interested college students. Last year Google funded 900 students, so we have seen an increase in funding for an additional 225 students over last year's program. Amazing. Thank you Google!

Now more specifically to Git. We received 36 student applications from almost that many students (a couple submitted more than one project idea). That works out to be .5% of the applications. Google graciously offered Git 6 student slots, which is .5% of the total number of slots Google funded this year. One of the criteria used by Google to allocate slots to organizations is the percentage of overall applications received.

This year we had a difficult time selecting students. There were many worthy applicants and applications, and just not enough slots to go around. I wish we had more slots to give, as there were even more students that we wanted to fund.

Student stipends for Google Summer of Code run at $4500 USD. If you work for a company with deep enough pockets to be able to make such a donation to a "Git summer intern", we'd love to talk to you.

If you are a student who wasn't selected, you should be receiving a more detailed message from me in the next few days regarding your proposal. I really want to let everyone know what happened with their proposal, including the general reasoning behind why the project wasn't selected. In many cases it simply was a lack of resouces, both in terms of mentors and in terms of limited slots. Due to the relatively large number of students it will probably take me a couple of days to write everyone. Please be patient.

*1*: http://google-opensource.blogspot.com/2008/04/announcing-accepted-student-proposals.html

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

These notes have now all been individually emailed to students.

As GSoC applications are considered private unless accepted into the program I have specifically avoided CC'ing these messages to the mailing list. Every message obviously contained the student's email address, but each also addressed specific parts of the student's non-public project proposal.

The way we selected our 6 students was driven by a number of factors:

 - availability of mentors

   As org admin I was trying to balance one student per mentor,
   so that each individual mentor could focus their available time
   to a single student's benefit.  Most mentors were willing to
   mentor only 1 or 2 specific project ideas.  To maximize our
   accepted students we had to accept a diverse range of projects.

 - limited slots

   With only 6 slots available to us in the end we had to make
   some tough decisions about which projects should be selected,
   and which wouldn't.  It would be nice if there were more slots
   then students (and we could take them all), but that is not the
   way such things work.

 - community interest

   We tried to select projects that will have a visible impact on
   the overall Git user community.

 - proposal quality

   We looked for well defined proposals that had measurable criteria
   for success, and a clear direction for reaching that goal within
   the time allotted by the GSoC calendar.

 - community interaction and student enthusiasm

   We looked for applications where the student was active on our
   IRC channel, or discussed their project on the mailing list, or
   significantly via private email with a potential mentor.

   In all such cases the students showed enthusiasm for the project
   idea and a genuine interest in making Git even better for everone.
   This was not required, but it certainly made the mentors feel
   that the student was more likely to be successful this summer.

If anyone has any questions, or would like further information about our selection process this year, please feel free to ask.

Oh, and last but not least, I _really_ want to thank our crew of 2008 mentors for helping with the evaluation process. They spent some pretty considerable time over the last few weeks talking to prospective students on IRC, this mailing list, and private email, as well as reviewing applications through the official GSoC web application portal thingy (which as it turns out is a lot less cool of a web application than it sounds). Their efforts were very much appreciated.

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

I have found three another Git-related Google Summer of Code 2008 projects by other organizations:

    Git plugin for Anjuta IDE  (GNOME)
    KDevelop DVCS support      (KDE)
    Git# implementation        (Mono Project)

Info from Shawn message, and above info can be found on git wiki at http://git.or.cz/gitwiki/SoC2008Projects

Jakub Narebski <jnareb@gmail.com> wrote:

This project was new to me; prior to your message I did not know about it. Thanks.

I contacted this student/mentor pair and offered them our mailing list address if they have questions. Apparently the project is trying to create some common DVCS abstractions but wants to use Git as the first supported tool.

I was talking to one of the two students on #git the other day. Robin and I both think they are probably better off just taking jgit and compiling it with ikvm so it runs on the Mono CLR. From there they can build their interface in C#. Excluding the copyright header in every source file, jgit is about 24,300 lines of code right now. That's a lot to write in a summer, especially if you don't know Git as well as say I do.

There is some concern from people who are close to the summer of code program that two students working on the same project this summer may result in one's success being dependent upon the other's success. This sort of dependency is not permitted under the Summer of Code rules, as it can be quite unfair to an otherwise successful student.

It will be interesting to see how everyone's project turns out at the end of the summer.

On Sat, 26 Apr 2008, Shawn O. Pearce wrote:

By the way, it is a bit strange that Google Summer of Code 2008 pages 
are not fully indexed.  Currently searching for "git soc 2008" from 
"Search Google Code:" search form finds only organization info for Git 
Community, "Git plugin for Anjuta IDE" project, SoC2008Template 
(Note, this template is blatantly plagiarized from Git's SoC 
template ;-), and netconf project for Debian which uses Git repository 
but is not about git in any way; none of other were found.
 

Have they contacted Git Community (IRC channel, mailing list, individual developers) for help, or did you contacted them, as with "KDevelop DVCS support"?

With these two projects, and egit/jgit for Eclipse, and also planned Git 
support in NetBeans IDE, there would be Git support in I think most 
used IDEs... What's left is something akin to AnkhSVN, i.e. support for 
Git in Visual Studio; perhaps Git# projects would help with it...
 

I think it is a very good idea, because in my (certainly biased) opinion Git has best design and best model of DVCS. It also has many interesting features: working with multiple branches in single repository, bisect to find where bug was introduced, blame/annotate working across code movement and possibly ignoring whitespace changes (although I guess that it would be nice to have interface to pickaxe search instead/in addition).

I wonder how much will be done; I guess it can borrow at least a bit 
from QGit (history viewer) and KGit (commit tool).
 

I was wondering how this have passed GSoC projects screening...

Jakub Narebski <jnareb@gmail.com> wrote:

It is strange. But I'm sure its something like the site is indexed by Google itself, and the page rank algorithm is classifying most of the pages as too low to be worth returning due to the low number of hyperlinks going in.

Apparently our GSoC work has been useful to others outside of Git.
Excellent.  GSoC has started to become even more of a pet project
of mine, so I'm glad to see people outside of our community have
found our work useful.
  

They haven't contacted me or anyone I know. I looked up an email address for the mentor (couldn't locate one for the student) and sent them an email, as I did for KDevelop. Except I wrote it after my reply to you so I didn't mention it in my reply to you. Ok, so now I have mentioned it. ;-)

I haven't heard anything about Git in NetBeans lately.  I'm hoping
that one day a devoted NetBeans user will come along and pester
us to break jgit out of the egit repository, so that they can
use it within NetBeans without lugging around Eclipse code they
don't need.  The code is already built with that in mind, it just
has the unfortunate fate of being mingled in the same repository
as the egit code.
  

Marek Zawirski (the Git GSoC student adding push support to jgit) mentioned something about this to me earlier this week. I made a remark about it on #gsoc, and the Google folks who do most of the work for GSoC had not heard about it before my comment. With so many students and projects I am not surprised that they cannot screen everything.

Most of the screening is left up to the mentors themselves. So in this case the Mono mentors must have felt that this project was large enough and important enough to justify using two student slots, and that either they didn't know about the rule, were going to ignore the rule, or would be able to structure the projects to avoid this dependency.

I hadn't realized Git was so important to the Mono folks. I thought they were still on SVN. In any event, it is interesting that they are building IDE support. Its depressing that Microsoft managed to fracture the development communities into Java vs. C# and that they use different VMs, resulting in it being more likely that code will be rewritten rather than reused.

Sverre Rabbelier <alturin@gmail.com> wrote:

I have been considering it. But haven't proposed the idea myself quite yet.

We are all working on very different projects. But I see roughly three classes of discussions that are likely to occur:

  * seemingly stupid questions (aka read the manual or faq)

  There's no such thing as a stupid question, only stupid answers.
  But one reason we have these wonderful mentors is they can be a
  safe place for you to bounce ideas off without inciting a flame
  war on the mailing list.

  * fine grained project specific details

  These are maybe too specific to your project to really spam close
  to 900 people on the main git mailing list, but are still worth
  discussion.  Often these sorts of discussions happen off-list
  among a few interested contributors anyway, even in non-GSoC git
  related projects.

  These probably should happen between you, your mentor(s) and a
  handful of others who your mentor has introduced you to as being
  interested in your work, and as a resource for you to go to for
  assistance (see the first class of discussion).

  * more project wide discussions

  These really should happen on the git mailing list.  You really
  want feedback from potential users, and you really want to get a
  wider audience for your work.  As your project evolves and takes
  shape your mentor should be encouring you to start posting bits
  of it for more general discussion.

That said, if the students want to set up a mailing list to help each other out, go ahead. And feel free to invite your mentors, or not. ;-)

For the record, the best way to reach me is this email address, or as "spearce" on irc.freenode.net in #git and/or #gsoc. I'm never on an IM network, and I really don't like to visit web forums. If it doesn't email to this address where I can read and reply, its not something I am interested in.