Google Summer of Code 2009

Google Summer of Code 2009

[Shawn O. Pearce]

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

-- 
Shawn.

Re: Google Summer of Code 2009

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

On Wed, Jan 07, 2009 at 10:30:33AM -0800, "Shawn O. Pearce" <spearce@spearce.org> wrote:
> The ideas box is once again open for suggestions.  Please start
> proposing student projects, and possible mentors.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Google Summer of Code 2009

[Alex Riesen]

2009/1/7 Shawn O. Pearce <spearce@spearce.org>:
>
>  Organization ideas page:
>    http://git.or.cz/gitwiki/SoC2009Ideas
>

BTW, what happened to GitTorrent?

Re: Google Summer of Code 2009

[Shawn O. Pearce]

Alex Riesen <raa.lkml@gmail.com> wrote:
> 2009/1/7 Shawn O. Pearce <spearce@spearce.org>:
> >
> >  Organization ideas page:
> >    http://git.or.cz/gitwiki/SoC2009Ideas
> 
> BTW, what happened to GitTorrent?

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

-- 
Shawn.

Re: Google Summer of Code 2009

[Johannes Schindelin]

Hi,

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

> Alex Riesen <raa.lkml@gmail.com> wrote:
> > 2009/1/7 Shawn O. Pearce <spearce@spearce.org>:
> > >
> > >  Organization ideas page:
> > >    http://git.or.cz/gitwiki/SoC2009Ideas
> > 
> > BTW, what happened to GitTorrent?
> 
> I got lazy and didn't copy everything over.  ;-)

Actually, that would have been lazy. :-)

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

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

Re: Google Summer of Code 2009

[Alex Riesen]

2009/1/8 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> 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...
>
> 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.

Takes courage, saying things like that :)

Re: Google Summer of Code 2009

[Sam Vilain]

On Thu, 2009-01-08 at 00:30 +0100, Johannes Schindelin wrote:
> 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.

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.

Re: Google Summer of Code 2009

[Jakub Narebski]

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

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

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.
 
> The ideas box is once again open for suggestions.  Please start
> proposing student projects, and possible mentors.

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

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

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

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Google Summer of Code 2009

[Johannes Schindelin]

Hi,

On Sat, 10 Jan 2009, Jakub Narebski wrote:

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > The application answers really need to be reworked; we need to
> > address our 2008 results in these parts.
> 
> By the way, do you know what happened with git-sequencer project? 

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

Re: Google Summer of Code 2009

[Andreas Ericsson]

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Google Summer of Code 2009

[Christian Couder]

Hi,

Le samedi 10 janvier 2009, Johannes Schindelin a écrit :
> Hi,
>
> On Sat, 10 Jan 2009, Jakub Narebski wrote:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> > > The application answers really need to be reworked; we need to
> > > address our 2008 results in these parts.
> >
> > By the way, do you know what happened with git-sequencer project?
>
> -- 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 --

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.

Re: Google Summer of Code 2009

[Christian Couder]

Le lundi 12 janvier 2009, Andreas Ericsson a écrit :
> 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. 

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.

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

I don't think things are so simple.

Regards,
Christian.

Re: Google Summer of Code 2009

[Johannes Schindelin]

Hi,

On Mon, 12 Jan 2009, Andreas Ericsson wrote:

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

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

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

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

Re: Google Summer of Code 2009

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 12 Jan 2009, Andreas Ericsson wrote:
> 
> > 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.
> 
> I don't know if I like co-mentoring; I always had the impression that this 
> does not work all that well.

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.

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

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

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.

-- 
Shawn.

Re: Google Summer of Code 2009

[Shawn O. Pearce]

Christian Couder <chriscool@tuxfamily.org> wrote:
> Le lundi 12 janvier 2009, Andreas Ericsson a écrit :
> > 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.
> 
> I don't think things are so simple.

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.

-- 
Shawn.

Re: Google Summer of Code 2009

[Shawn O. Pearce]

Andreas Ericsson <ae@op5.se> wrote:
> 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.

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.

-- 
Shawn.

Re: Google Summer of Code 2009

[Johannes Schindelin]

Hi,

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

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 12 Jan 2009, Andreas Ericsson wrote:
> > 
> > > 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.
> > 
> > I don't know if I like co-mentoring; I always had the impression that 
> > this does not work all that well.
> 
> 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.

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.

> This year I may not be able to be a mentor for GSoC.

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

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

Hehe.  I am very proud that we are able to hold such a 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.
>  
> > 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.
> 
> 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.

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.

> GSoC is about getting these folks _involved_, so that 40 years from now, 
> open source is just as viable as it is today.

It will probably take over even more of our world.

Ciao,
Dscho

Re: Google Summer of Code 2009

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 12 Jan 2009, Shawn O. Pearce wrote:
> 
> > This year I may not be able to be a mentor for GSoC.
> 
> Pity.  But you started the preparation for the new application, thank you 
> very much.  Will you be able to be administrator again?

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.

-- 
Shawn.

Re: Google Summer of Code 2009

[Stephan Beyer]

Hi,

Jakub Narebski wrote:
> 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.

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.

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F