Google Summer of Code 2009

Google just pre-announced that Summer of Code 2009 will run. Its going to be a bit smaller than last year's program due to the poor worldwide economic climate, but the open source community is quite fortunate that Google is footing the bill for yet another summer of students hacking on open source projects.

Given our success last year, I think we should try applying again this year as a mentoring organization. I've started to put the wiki pages together by cloning last year's stuff:

  Organization application:
    http://git.or.cz/gitwiki/SoC2009Application

  Organization ideas page:
    http://git.or.cz/gitwiki/SoC2009Ideas

FWIW, the folks who organize GSoC thought our ideas page is among the better ones they've seen year-after-year. So I'm largely keeping the same format. :-)

The application answers really need to be reworked; we need to address our 2008 results in these parts.

The ideas box is once again open for suggestions. Please start proposing student projects, and possible mentors.

Since the program is smaller, there is a chance we won't be accepted this year due to space constraints. But I think its still worthwhile to prepare everything and hope for the best. And before you can ask, no, my employee status with OSPO doesn't improve our odds for acceptance. :-)

On Wed, Jan 07, 2009 at 10:30:33AM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:

I think restartable git-clone from last year is still actual, and would be nice to have.

2009/1/7 Shawn O. Pearce <spearce@spearce.org>:

BTW, what happened to GitTorrent?

Alex Riesen <raa.lkml@gmail.com> wrote:

I got lazy and didn't copy everything over.  ;-)

GitTorrent and restartable clone both should probably be on the 2009 idea list, though GitTorrent already has a code base from the failed 2008 project that someone might be able to start and pick up from...

Hi,

On Wed, 7 Jan 2009, Shawn O. Pearce wrote:

Actually, that would have been lazy. :-)

According to

	http://repo.or.cz/w/VCS-Git-Torrent.git

Joshua is still working on it (albeit slowly).

However, from what Sam said at the GitTogether, it might be a much better idea to look at the existing code as a fact-finding experiment, scrap it (excluding the experience), and start modifying git-daemon.

AFAICT Sam has a pretty clear idea how to go about it, and staying with C should make it much easier for other people to comment.

Note that there has been a flurry of emails on the gittorrent list a few weeks back, where somebody challenged the approach Sam wants to take, saying that BitTorrent has some very nice features that are absolutely necessary, such as its pretty awkward custom encoding.

But AFAICT Sam did a pretty good job at dispelling all of the objections.

Ciao, Dscho

2009/1/8 Johannes Schindelin <Johannes.Schindelin@gmx.de>:

Takes courage, saying things like that :)

On Thu, 2009-01-08 at 00:30 +0100, Johannes Schindelin wrote:

Yes, this is accurate as I know it. I've renamed and reworded the heading under the SoC2009Ideas page to point to the most current design. It's all in a "just add JFDI" point right now I think ;-).

Sam.

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

By the way, do you know what happened with git-sequencer project? 

If I remember correctly there was agreement on sequences mini-language
(I think), and there was git-sequencer prototype in shell, using
git-cherry-pick if I remember correctly, and even git-rebase and
git-am etc reworked to make use of git-sequencer.  Stephan Beyer wrote
that he has some preliminary version of builtin git-sequencer (in C),
and that it makes git-rebase--interactive and like faster than current
implementation... but builtin sequencer never materialized on git
mailing list as a patch, if I remember correctly, and of course it was
not merged into git either.
 

Hmm... take a look what features competition has (Darcs, Bazaar-NG, Subversion, Mercurial, Monotone)...

Perhaps at least _one_ project. I think that resumable clone / resumable fetch would be a good thing to have...

Hi,

On Sat, 10 Jan 2009, Jakub Narebski wrote:

-- snip --
commit 3bfd6761ce2f769746c6b84be97f7da0cad7cad1
Author: Stephan Beyer <s-beyer@gmx.net>
Date:   Wed Jan 7 19:07:31 2009 +0100

    builtin-sequencer.c/prepare_commit_msg_hook: tiny simplification

    Thanks to Christian.
-- snap --

Ciao, Dscho

Hi,

Le samedi 10 janvier 2009, Johannes Schindelin a écrit :

Yes, Stephan, Daniel and me are still working on it but very slowly. You can see what happens on the repo here:

http://repo.or.cz/w/git/sbeyer.git?a=shortlog;h=refs/heads/seq-builtin-dev

May be we should move our discussions, patches and everything on the git mailing list as it may motivate us and people on the list to help.

One good thing too would be if Stephan could share is todo list.

By the way don't hesitate to put us in CC :-)

Regards, Christian.

Hi,

Jakub Narebski wrote:

You remember and conclude correctly.

As Christian pointed out, we are working on it. Development didn't make any real progress for a long time because of different personal reasons. (If you're interested: an important exam at the end of September, some other work besides, wrong priorities in time management, some kind of "burnout" after the exam which made me avoid any kind of productive work for a long time... it went away in between but came back later...)

Now, again, I'm highly motivated to get it merged into pu or next before the end of January. I hope, Christian or Daniel will kick me in the back if this is not going to happen :-) The next days some tiny and some bigger patches will follow. Commits that have been lying around in my repo for a _long_ time.

In this time I try to address the rest of my TODO list which emerged
from a very chaotic sticky note[1] and is, well, just chaotic.
It contains items about...
 - some internal changes (simplifications, code reuse),
 - some changes in the output of sequencer,
 - some better code documentation (one item for a part of sequencer
   itself, one item for its test suite t3350),
 - check some stuff and fix if needed
   (e.g. whether sequencer changes this or that behavior (for
   rebase or am) that I haven't taken care of yet),
 - and the last item is to check/incorporate the git-rebase --root
   patches and/or fix sequencer to work with them (if needed).
   (I haven't taken one look at these patches, so I don't know
   if it's really necessary.)

It's not too much, but every single change can generate a bug and, thus, hassle. :-)

Well, this is the current state of the git-sequencer project. Thanks for the question and the prodding in the other thread (although the problem there was solved much simpler without sequencer.)

Regards,
  Stephan

Footnotes.
 1. I mean those fancy yellow desktop notes provided by tools like
    "knotes" -- now uninstalled from my desktop machine, because
    there are *useful* tools like outliners that _help_ to
    manage ideas, todo lists, etc in a non-chaotic way.

Just chiming in that I can probably help mentoring whoever goes with libgit2. I do not have enough spare time for me to promise that I can be there as much as I think is necessary and proper, but I'll gladly help out.

On a side-note, I think all mentors should urge the students in the strongest possible terms to deliver their work to git@vger as soon as possible. From previous years experience, successful projects are those that the list sees code from within a week or two after the project's started, while the projects that are kept in the dark rarely (if ever?) finish successfully.

Le lundi 12 janvier 2009, Andreas Ericsson a écrit :

I agree, but I think there is also a merge problem. I mean we should also perhaps urge students to get what they have done merged as soon as possible even if it means that they rework 5 or 10 time the code instead of developing features according to the schedule.

But unfortunately even something merged into next can be removed afterwards, so it's really difficult, because big features cannot for obvious reasons be merged into master and the git release cycle doesn't always go along well with the GSoC schedule.

I don't think things are so simple.

Regards, Christian.

Christian Couder <chriscool@tuxfamily.org> wrote:

Nope, they aren't. But the pattern is generally there, when you look at all GSoC projects in aggregate.

Students who are involved with their community are far more likely to have a successful project. In most communities, getting code posted on the discussion list and actually discussing it is a very important part of that involvement.

Hi,

On Mon, 12 Jan 2009, Andreas Ericsson wrote:

I don't know if I like co-mentoring; I always had the impression that this does not work all that well.

Nope, that is just plainly incorrect.

The most successful GSoC project we had was Miklos' builtin-merge, but the code had to grow to a state that both him and me were comfortable with a submission to git@vger.

The _communication_ should be open, and much of it on the mailing list, I agree, but _only_ after the student is familiar enough with the aspects of her project (including some familiarity with the source code).

I will _not_ force a student to ask questions openly that he finds embarassing.

Ciao, Dscho

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

I haven't tried it myself, so I can't comment. I thought though that Daniel and Christian's mentoring went rather well, but maybe that's just me.

This year I may not be able to be a mentor for GSoC. Even assuming we are selected again we're likely to only have two students, given the size of the program and the size of our organization's community. I will most likely be hosting an intern at day-job, and I do want to maintain some sort of contribution to Git, without hurting my day job performance... so my time this summer is probably going to be somewhat limited.

Heh. I'd wager the most successful GSoC project was Marek's push support for JGit. Having ObjectWriter available has opened up the doors to support a lot of code in JGit, like the full protocol suite, and bundles. Without it I wouldn't have gotten as far as I did in Gerrit.

In terms of value, to me as a contributor, Marek's work gave me a foundation we could build on and get stuff done. Miklos' merge is great, but I don't think we gained nearly as many features as we did with Marek's contribution.

Anyway, I don't want to get into a "my student was better!" contest.
I just think that we had a very successful year this year, with a
few really great projects being contributed to the community as a
result of our students' hard work.
 

I agree. The first few weeks are really critical to the student. They are still trying to find their way around the code base and don't want to look like an idiot. Nobody wants to look like an idiot, especially in public, and especially when they have been "hired" to do a particular job.

But... part of the reason GSoC exists is to get students involved in open source. The rest of us don't come to Git with mentors we can ask the "stupid" questions to. We come here and have to ask what we need to ask, on the public mailing list, complete with archives for the rest of time. As mentors we should be trying to encourage our students to work in this, or any other, open source community. GSoC is about getting these folks _involved_, so that 40 years from now, open source is just as viable as it is today.

Hi,

On Mon, 12 Jan 2009, Shawn O. Pearce wrote:

That impression came from a few conversations at the mentor summit, BTW. I cannot really comment on C & D... as Christian pointed out, they are still a bit secretive, even long after the official end of the project.

However, I have to mention that some projects (SIP communicator for example) made it a _requirement_ to have pairs of mentors. But then, they had the "disappearing mentor" syndrome already, so who can blame them for that.

Pity. But you started the preparation for the new application, thank you very much. Will you be able to be administrator again?

Hehe.  I am very proud that we are able to hold such a contest.

I do not think that both of your paragraphs contradict each other. Many students need a bit of hand-holding until they realize that everybody is cooking with water. At the end of the day, everybody has some brilliant and some stupid ideas.

But it takes some getting used to to voice ideas in public, risking some friendly jokes about your mental state or the quality of your smokables.

I actually see a lot of value in GSoC as a tools to get more students through that period, especially students from parts of this planet whose culture is so different from the "Western" culture shaped by TV, consumism and the lack of physical insecurity, that they are rather intimidated by the ways of Open Source.

It will probably take over even more of our world.

Ciao, Dscho

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

Yes, I can certainly do the administrative functions again this year, and would be more than happy to do it. Most of it happens before the students start work, and thus before any theoretical intern would also join me at day-job. To be honest I spend most of the time on the org application itself; its all down hill from there.

Andreas Ericsson <ae@op5.se> wrote:

Thanks.  I'd love to see a libgit2 project this summer.

If we do have such a thing, and if I'm still wearing the maintainer hat for libgit2, I think it would be improper for me to be the mentor for the student. Just as Junio abstains from mentoring any students in GSoC, to prevent potential bias during patch review, I probably should abstain in the case of libgit2. Or at least move the project to a dual-maintainer approach like we use with JGit, so the other maintainer is the one doing the actual review and patch acceptance.