Google Summer of Code 2013 (GSoC13)

Google Summer of Code 2013 (GSoC13)

[Thomas Rast]

Hi,

Google announced the 2013 incarnation of the Google Summer of Code
program on Feb 11:

  http://www.google-melange.com/gsoc/homepage/google/gsoc2013

Git has taken part in previous years, so I figure somebody should get
the ball rolling again!  The following items need to be sorted out:

* We need an org admin.  AFAIK this was done by Peff and Shawn in
  tandem last year.  Would you do it again?

* We should prepare an "ideas page".  Last year, Peff made one on

    https://github.com/peff/git/wiki/SoC-2012-Ideas

  I couldn't edit it there over git access[1], so I made a clone in "my"
  github wiki:

    https://github.com/trast/git/wiki/SoC-2013-Ideas

  I'll volunteer to manage that wiki[2].  Please either edit it
  directly, or send me patches or pull requests.  I won't really have
  time to properly review them, but I'll do my best to merge everything.

* Naturally that ideas page is a bit stale now, and three projects
  shorter.  Please propose new ideas and refresh or delete the old ones!
  In particular some projects spawned long discussions on the list, and
  the results of those discussions should be integrated to avoid deja
  vus.

* We should have a pool of mentors and rough mentor-project matchings.
  I gathered a -- certainly incomplete -- list of previous mentors and
  students in the Cc field; maybe some of you are interested again?  If
  so, propose your own ideas and/or list yourself in the "proposed
  mentors" for some existing projects.  (I cleared all those fields for
  now.)

* Even if you don't want to mentor, you can still contribute by helping
  with discussing and ranking proposals, especially immediately before
  and after the project submission deadline (May 3).

If we want to participate again, we need to get together an org
application until *March 29* 19:00 UTC, and it won't exactly hurt to
have the ideas page settled until then too.

It would be really nice if we could do this again, I think GSoC is a
great opportunity both for Git and the involved students.

Cheers
Thomas


Footnotes: 
[1]  That's a bit silly really, since I *can* edit it via the web
interface.  Peff, perhaps you can get that fixed?

[2]  Unless Peff wants to take it over again?  You could just pull it
from the git version, it's based on your history.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Google Summer of Code 2013 (GSoC13)

[Jeff King]

On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:

> * We need an org admin.  AFAIK this was done by Peff and Shawn in
>   tandem last year.  Would you do it again?

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.

And I do not want to blame the students here (some of whom are on the cc
list :) ). They are certainly under no obligation to stick around after
GSoC ends, and I know they have many demands on their time. But I am
also thinking about what Git wants to get out of GSoC (and to my mind,
the most important thing is contributors).

As far as merged code, I think part of the problem is that git is fairly
mature at this point. The most interesting projects are of a bigger
scope than a student with no experience in the code base can do in a
summer project. Maybe that means we need to do a better job of breaking
projects down into reasonably sized sub-components. Or maybe it means
the project is hitting a point of diminishing returns for GSoC. I don't
know.

There are a few counterpoints I can think of:

  - Even though not all projects are winners, _some_ are. I see Carlos
    and Ram on the cc list, two people who started as GSoC students and
    stuck around.

  - There is also the angle that even if _Git_ doesn't benefit directly
    from people sticking around, those people may float into other open
    source projects and work on them. Which makes the world a better
    place on the whole.

So I don't know. Those are just some things that have been floating
around in my head. Feel free to ignore or discuss.

But thanks for getting the ball rolling, Thomas. If we are going to do
it, sooner is better, and if we aren't, then we should probably do so
consciously, and not just miss the deadline accidentally. :)

> * We should prepare an "ideas page".  Last year, Peff made one on
> 
>     https://github.com/peff/git/wiki/SoC-2012-Ideas
> 
>   I couldn't edit it there over git access[1], so I made a clone in "my"
>   github wiki:
> [...]
> [1]  That's a bit silly really, since I *can* edit it via the web
> interface.  Peff, perhaps you can get that fixed?

Ugh, I would have to write ruby code to fix that. I'll try to trick
somebody else here into fixing it. :)

> [2]  Unless Peff wants to take it over again?  You could just pull it
> from the git version, it's based on your history.

I think it is as good on your repo as on mine. The kernel.org wiki is
also up, and the github/peff/git one was supposed to be temporary. But I
really hate any wiki that I cannot edit with vim. I guess we need to
have a discussion as a group about where the "official" wiki should
live, and it should go there (I can also put it at github/git/git, which
is a more sane place; but I do not want to compete with kernel.org's
wiki unless there is community consensus that we are moving).

-Peff

Re: Google Summer of Code 2013 (GSoC13)

[Thomas Rast]

Thomas Rast <trast@inf.ethz.ch> writes:

> * We should prepare an "ideas page"[...]
>     https://github.com/trast/git/wiki/SoC-2013-Ideas

>From where I'm currently sitting, I won't have the time to mentor this
year.  So my two earlier proposals are essentially up for grabs:

1. Improving parallelism in various commands
   -----------------------------------------
 
   Git is mostly written single-threaded, with a few commands having
   bolted-on extensions to support parallel operation (notably git-grep,
   git-pack-objects and the core.preloadIndex feature).
 
   We have recently looked into some of these areas and made a few
   optimizations, but a big roadblock is that pack access is entirely
   single-threaded.  The project would consist of the following steps:
 
    * In preparation (the half-step): identify commands that could
      benefit from parallelism.  `git grep --cached` and `git grep
      COMMIT` come to mind, but most likely also `git diff` and `git log
      -p`.  You can probably find more.
 
    * Rework the pack access mechanisms to allow the maximum possible
      parallel access.
 
    * Rework the commands found in the first step to use parallel pack
      access if possible.  Along the way, document the improvements with
      performance tests.
 
   The actual programming must be done in C using pthreads for obvious
   reasons.  At the very least you should not be scared of low-level
   programming.  Prior experience and access to one or more multi-core
   computers is a plus.

This one is probably still a contender.  However, it might be worth
first looking into whether using libgit2 for pack reading would be
easier and faster, since it is written to be reentrant from the ground
up.


2. Improving the `git add -p` interface
   ------------------------------------

   The interface behind `git {add|commit|stash|reset} {-p|-i}` is shared
   and called `git-add--interactive.perl`.    This project would mostly
   focus on the `--patch` side, as that seems to be much more widely
   used; however, improvements to `--interactive` would probably also be
   welcome.

   The `--patch` interface suffers from some design flaws caused largely
   by how the script grew:

    * Application is not atomic: hitting Ctrl-C midway through patching
      may still touch files.

    * The terminal/line-based interface becomes a problem if diff hunks
      are too long to fit in your terminal.

    * Cannot go back and forth between files.

    * Cannot reverse the direction of the patch.

    * Cannot look at the diff in word-diff mode (and apply it normally).

   Due to the current design it is also pretty hard to add these features
   without adding to the mess.  Thus the project consists of:

    * Come up with more ideas for features/improvements and discuss them
      with users.

    * Cleanly redesigning the main interface loop to allow for the above
      features.

    * Implement the new features.

   As the existing code is written in Perl, that is what you will use for
   this project.

This has already featured twice, and resulted in proposals that were
insufficiently advanced and too little work for a GSoC.  If nobody feels
like extending it to a bigger project, I'll just scrap it.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Google Summer of Code 2013 (GSoC13)

[Ronan Keryell]

>>>>> On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast <trast@student.ethz.ch> said:

    Thomas>    The actual programming must be done in C using pthreads
    Thomas> for obvious reasons.

Are there obvious reasons OpenMP would not be enough to do the job?

It looks like a trade-off between the code readability & portability
versus the real expressiveness of what parallelism control details are
needed.
-- 
  Ronan KERYELL                            |\/  Phone:  +1 650 386 6482
  SILKAN Wild Systems                      |/)
  4962 El Camino Real #201                 K    Ronan.Keryell@silkan.com
  Los Altos, CA 94022                      |\   skype:keryell
  USA                                      | \  http://silkan.com

Re: Google Summer of Code 2013 (GSoC13)

[Ramkumar Ramachandra]

Thomas Rast wrote:
> 2. Improving the `git add -p` interface
>    ------------------------------------

>     * The terminal/line-based interface becomes a problem if diff hunks
>       are too long to fit in your terminal.

I don't know if it's worth coming up with another interface.  The best
solution for this is editor integration, in my opinion.  I use Magit
mostly for just the graphical staging/ unstaging.  There's also a
Fugitive.vim for vim.

>     * Cannot look at the diff in word-diff mode (and apply it normally).

Yes, this is a major limitation that would be nice to fix.
Also: Having to figure out, heuristically, when to actually turn it on
might be a worthwhile feature, especially for services like GitHub.

>    As the existing code is written in Perl, that is what you will use for
>    this project.

I don't know- is Perl a possible deterrent?
Won't getting a word-diff to apply involve C work though?  (patching
builtin/apply.c?)

Re: Google Summer of Code 2013 (GSoC13)

[Ramkumar Ramachandra]

[corrected David Barr's email address]

Jeff King wrote:
> And I do not want to blame the students here (some of whom are on the cc
> list :) ). They are certainly under no obligation to stick around after
> GSoC ends, and I know they have many demands on their time. But I am
> also thinking about what Git wants to get out of GSoC (and to my mind,
> the most important thing is contributors).
>
> As far as merged code, I think part of the problem is that git is fairly
> mature at this point. The most interesting projects are of a bigger
> scope than a student with no experience in the code base can do in a
> summer project. Maybe that means we need to do a better job of breaking
> projects down into reasonably sized sub-components. Or maybe it means
> the project is hitting a point of diminishing returns for GSoC. I don't
> know.

I'll be frank here.  I think the main reason for a student to stick
around is to see more of his code hit `master`.  I think it is
absolutely essential to get students constantly post iteration after
iteration on the list. It would be nice to get them connected with 2~3
people in the community who will follow their progress and pitch in
everytime they post an iteration.  It might also make sense to stage
their work in the main tree (a gsoc/ namespace?), so we can just
checkout to their branch to demo what they've done.

Also, we need more projects that will scratch everyday itches.  A
collection of related tiny features might not be a bad idea.  Often,
we risk erring on the side of too-big-for-one-summer when it comes to
specifying projects.  What's the harm of including something estimated
to take 80% of a summer?

On a related note, I don't like our Wiki.  It's down half the time,
and it's very badly maintained.  I want to write content for our Wiki
from the comfort of my editor, with version control aiding me.  And I
can't stand archaic WikiText.

Re: Google Summer of Code 2013 (GSoC13)

[Jeff King]

On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote:

> I'll be frank here.  I think the main reason for a student to stick
> around is to see more of his code hit `master`.  I think it is
> absolutely essential to get students constantly post iteration after
> iteration on the list. It would be nice to get them connected with 2~3
> people in the community who will follow their progress and pitch in
> everytime they post an iteration.  It might also make sense to stage
> their work in the main tree (a gsoc/ namespace?), so we can just
> checkout to their branch to demo what they've done.

I agree. One of the main problems with GSoC projects is that the student
goes away and works for a while, and then at the end does not
necessarily have something mergeable. That is not how regular
contributors work. They post works in progress, get feedback, and
iterate on ideas. They break work into easily digestable and reviewable
chunks. So maybe the mentors should be focusing more on that than on
actual code problems.

> Also, we need more projects that will scratch everyday itches.  A
> collection of related tiny features might not be a bad idea.  Often,
> we risk erring on the side of too-big-for-one-summer when it comes to
> specifying projects.  What's the harm of including something estimated
> to take 80% of a summer?

I very much agree with you here. One problem is that those smaller
projects often do not sound as grand or as interesting, and so students
do not propose them. We have to work with the applicants we get.

> On a related note, I don't like our Wiki.  It's down half the time,
> and it's very badly maintained.  I want to write content for our Wiki
> from the comfort of my editor, with version control aiding me.  And I
> can't stand archaic WikiText.

Agreed on all of those points. Putting the Wiki on GitHub fixes that.
But it means contributors need to have a GitHub account. On the other
hand, I think kernel.org wiki contributors need an account these days?
And GitHub is putting some active effort into finding and killing spammy
accounts, which might keep wiki spam down (I do not pay too much
attention to those efforts, but on kernel.org, it is mostly up to the
Git community to do it ourselves).

-Peff

Re: Google Summer of Code 2013 (GSoC13)

[Jonathan Nieder]

Hi,

Jeff King wrote:

> 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

Re: Google Summer of Code 2013 (GSoC13)

[Thomas Rast]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> [corrected David Barr's email address]
>
> Jeff King wrote:
>> And I do not want to blame the students here (some of whom are on the cc
>> list :) ). They are certainly under no obligation to stick around after
>> GSoC ends, and I know they have many demands on their time. But I am
>> also thinking about what Git wants to get out of GSoC (and to my mind,
>> the most important thing is contributors).
>>
>> As far as merged code, I think part of the problem is that git is fairly
>> mature at this point. The most interesting projects are of a bigger
>> scope than a student with no experience in the code base can do in a
>> summer project. Maybe that means we need to do a better job of breaking
>> projects down into reasonably sized sub-components. Or maybe it means
>> the project is hitting a point of diminishing returns for GSoC. I don't
>> know.
>
> I'll be frank here.  I think the main reason for a student to stick
> around is to see more of his code hit `master`.  I think it is
> absolutely essential to get students constantly post iteration after
> iteration on the list. It would be nice to get them connected with 2~3
> people in the community who will follow their progress and pitch in
> everytime they post an iteration.  It might also make sense to stage
> their work in the main tree (a gsoc/ namespace?), so we can just
> checkout to their branch to demo what they've done.

I agree, but I think there's an additional component.  Consider the 'log
-L' feature.  It's fairly workable, and I merge it in my own builds and
use it, but there were and are two main issues:

* The initial work by Bo was not in shape to be included, mostly because
  the code was too convoluted in the parts that process line ranges.

* The last version I posted was held up because there's _in principle_ a
  better way to do things, but it requires major refactorings of
  existing code.

I'm not going to try to discuss away the first one; it's also a failure
of myself as mentor.  However, as far as incomplete work goes, I think
the latter item is fairly symptomatic.  We underestimate the amount of
work required to polish and reroll a submission that a student would
deem "sufficiently working for inclusion", fixes to be done later.

So I agree with your suggestion:

> What's the harm of including something estimated to take 80% of a
> summer?

Maybe even less than 80%.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Google Summer of Code 2013 (GSoC13)

[Ramkumar Ramachandra]

Jeff King wrote:
> On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote:
>
>> I'll be frank here.  I think the main reason for a student to stick
>> around is to see more of his code hit `master`.  I think it is
>> absolutely essential to get students constantly post iteration after
>> iteration on the list. It would be nice to get them connected with 2~3
>> people in the community who will follow their progress and pitch in
>> everytime they post an iteration.  It might also make sense to stage
>> their work in the main tree (a gsoc/ namespace?), so we can just
>> checkout to their branch to demo what they've done.
>
> I agree. One of the main problems with GSoC projects is that the student
> goes away and works for a while, and then at the end does not
> necessarily have something mergeable. That is not how regular
> contributors work. They post works in progress, get feedback, and
> iterate on ideas. They break work into easily digestable and reviewable
> chunks.

> So maybe the mentors should be focusing more on that than on
> actual code problems.

Take what I'm about to say with a pinch of salt, because I've never mentored.

Mentors often don't provide much technical assistance: students should
just post to the list with queries, or ask on #git-devel.  Mentors
serve a different purpose; their primary responsibility, in my
opinion, is to teach the student a sustainable productive workflow.
This means: profiling them to figure out where they're losing out.  Do
they have the habit of:
- posting to the list regularly?
- CC'ing the right people?
- iterating quickly after reviews?
- using gdb efficiently to quickly understand parts?
- using git efficiently for the rebase/ patch workflow?

>> Also, we need more projects that will scratch everyday itches.  A
>> collection of related tiny features might not be a bad idea.  Often,
>> we risk erring on the side of too-big-for-one-summer when it comes to
>> specifying projects.  What's the harm of including something estimated
>> to take 80% of a summer?
>
> I very much agree with you here. One problem is that those smaller
> projects often do not sound as grand or as interesting, and so students
> do not propose them. We have to work with the applicants we get.

We have to post well-crafted proposals like this to pique their interest.

>> On a related note, I don't like our Wiki.  It's down half the time,
>> and it's very badly maintained.  I want to write content for our Wiki
>> from the comfort of my editor, with version control aiding me.  And I
>> can't stand archaic WikiText.
>
> Agreed on all of those points. Putting the Wiki on GitHub fixes that.
> But it means contributors need to have a GitHub account. On the other
> hand, I think kernel.org wiki contributors need an account these days?
> And GitHub is putting some active effort into finding and killing spammy
> accounts, which might keep wiki spam down (I do not pay too much
> attention to those efforts, but on kernel.org, it is mostly up to the
> Git community to do it ourselves).

No, I'm against using the GitHub Wiki for neutrality reasons.  There
is one easy way to fight spam: don't expose a web-based editing
interface at all.  It's mainly going to be maintained by the
community, and we're all much more comfortable in our editors and git.
 We can give the regulars direct commit access and ask the rest to
submit pull requests.  Make it cost pennies, so any of us can easily
afford it: just a cheap domain, DNS, and static HTML hosting.

Re: Google Summer of Code 2013 (GSoC13)

[Thomas Rast]

Ronan Keryell <Ronan.Keryell@silkan.com> writes:

>>>>>> On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast <trast@student.ethz.ch> said:
>
>     Thomas>    The actual programming must be done in C using pthreads
>     Thomas> for obvious reasons.
>
> Are there obvious reasons OpenMP would not be enough to do the job?
>
> It looks like a trade-off between the code readability & portability
> versus the real expressiveness of what parallelism control details are
> needed.

Except for the added dependency you mean?

I'm not sure exactly what the capabilities of OpenMP are that would help
here, but most likely it would work.  It wouldn't really change the
amount of work needed, though, since the main work is in shuffling
around the existing code paths to be amenable to parallel access in the
first place.  A "dumb" parallelization (i.e., just locking around all
shared structures) POC yielded very little speedup because of lock
contention.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Google Summer of Code 2013 (GSoC13)

[Thomas Rast]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

>>     * Cannot look at the diff in word-diff mode (and apply it normally).
[...]
> Also: Having to figure out, heuristically, when to actually turn it on
> might be a worthwhile feature, especially for services like GitHub.

Actually that's a pretty cute idea of its own.  You could call it
--smart-diff or some such, and define its output as "whatever diff
format git thinks would be appropriate".

And given the current state of diff pipeline refactorization, the effort
is probably on the order of magnitude of a GSoC...

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Google Summer of Code 2013 (GSoC13)

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

> Take what I'm about to say with a pinch of salt, because I've never mentored.
>
> Mentors often don't provide much technical assistance: students should
> just post to the list with queries, or ask on #git-devel. Mentors
> serve a different purpose; their primary responsibility, in my
> opinion, is to teach the student a sustainable productive workflow.

I basically agree.  One of the most important jobs of mentors is to
make sure there are people available to provide prompt technical
assistance, hopefully before the project begins.

[...]
> - using gdb efficiently to quickly understand parts?

Oh, dear.  I hope not. ;-)

Thanks,
Jonathan

Re: Google Summer of Code 2013 (GSoC13)

[Jens Lehmann]

Am 18.02.2013 20:45, schrieb Thomas Rast:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> What's the harm of including something estimated to take 80% of a
>> summer?
> 
> Maybe even less than 80%.

I didn't regret at all having split the summer's topic I mentored
into smaller pieces. That made it easy to post patches to the list
rather early (and IIRC some of them hit master before the end of
the GSoC).

Re: Google Summer of Code 2013 (GSoC13)

[Jens Lehmann]

Am 18.02.2013 20:34, schrieb Jonathan Nieder:
> 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).

That's my experience too. Also I think it really makes sense to have a
co-mentor so you can balance the load a bit.

> I'd be happy to help on a project with 1 or 2 co-mentors.

Same here.

Re: Google Summer of Code 2013 (GSoC13)

[Thomas Rast]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

[...]
>>> On a related note, I don't like our Wiki.  It's down half the time,
>>> and it's very badly maintained.  I want to write content for our Wiki
>>> from the comfort of my editor, with version control aiding me.  And I
>>> can't stand archaic WikiText.
>>
>> Agreed on all of those points. Putting the Wiki on GitHub fixes that.
>> But it means contributors need to have a GitHub account. On the other
>> hand, I think kernel.org wiki contributors need an account these days?
>> And GitHub is putting some active effort into finding and killing spammy
>> accounts, which might keep wiki spam down (I do not pay too much
>> attention to those efforts, but on kernel.org, it is mostly up to the
>> Git community to do it ourselves).
>
> No, I'm against using the GitHub Wiki for neutrality reasons.  There
> is one easy way to fight spam: don't expose a web-based editing
> interface at all.  It's mainly going to be maintained by the
> community, and we're all much more comfortable in our editors and git.
>  We can give the regulars direct commit access and ask the rest to
> submit pull requests.  Make it cost pennies, so any of us can easily
> afford it: just a cheap domain, DNS, and static HTML hosting.

I suppose since github's wiki system (gollum) is open source [1] it
wouldn't be too hard to set up another instance somewhere.  Bonus points
for importing all the old data in mediawiki format first, which is also
apparently supported.

But that just shifts the point of failure from the entire github team to
one or two people who end up administering the server.

Perhaps a better solution would be to ask Scott or Peff to create a
gollum instance under git-scm.com, which they're already hosting?  (It
seems people got over *that* neutrality issue quickly enough.)  Push
rights could be given to interested regulars.  It would then at least be
independent in name.


Footnotes: 
[1]  https://github.com/github/gollum

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Google Summer of Code 2013 (GSoC13)

[Ramkumar Ramachandra]

Jonathan Nieder wrote:
> Hi,
>
> Jeff King wrote:
>
>> 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.

The point is that we must be willing to spend time learning what went
wrong the previous summer, and how to improve upon it.  There's no
point in doing a lather-rinse-repeat after many consecutive failures.

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

Why, exactly?  Git for embedded devices?

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

I didn't understand this: you want cgit in-tree?

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

I can't see a roadmap for gradually phasing out `rebase -i` as more
and more of its functionality is built into the sequencer.  Would you
start by using `cherry-pick --continue` in the special case of
consecutive `pick` or `revert` operations (yuck)?  The sequencer
currently has a continuation logic that we can leverage, but how will
it call out to shell functions to do specific tasks (like `fixup`,
which is not yet implemented)?  Really, the only way I see is to
duplicate the functionality of `rebase -i` in C, and throw away the
shell script when we're sure we're done.

For usable svn remote helper, the major TODO is a git -> svn bridge.
My previous effort (which was a long time) was stalled because we
needed a way to persist blobs of text referenced by marks, and
retrieve them on demand.  Building this bridge is hard enough already,
and I think we should just focus on an independent git -> svn bridge
to put into contrib/svn-fi as a deliverable.  It doesn't have to have
anything to do with remote helpers at all.

>  - drag-and-drop cherry-pick in gitk

You expect someone to write Tcl/Tk today?  Do a `git log gitk-git/`
and tell me how many people are writing it.

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

Overkill.  I just symlink to bin-wrapper/git from a place high up in
my $PATH.  If anything, we should be making it easier for ourselves to
run different versions of git right from $HOME, much like rbenv.
System-wide installs are taken care of by the distribution package
managers, and I doubt they need any help from us.

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

I personally don't care for notes much, because I can't see practical
usecases.  I'd much rather fix something that's much more widely used
and broken: submodules.

Re: Google Summer of Code 2013 (GSoC13)

[Jeff King]

On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote:

> Some potential projects (unfiltered --- please take them with a grain
> of salt):
> [...]
>  - 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

I know you said a grain of salt, so please don't feel like I'm beating
up on your idea. I'm picking this one because I think it has some
characteristics of projects that have not gone well in the past, so it's
a good illustrative example.

IMHO, this is the type of project that is likely to fail, because most
of the work is not technical at all, but political. Changing the default
refspecs is a few lines of code. But the hard part is figuring out where
they should go, the implications of doing so, and how people are going
to react. And it's intimately tied to how we have considered refactoring
the default ref namespaces, which is a messy discussion with a lot of
different options (and implications, and backwards compatibility issues,
etc). Plans need to be laid for deprecating old things, and handling the
transition to the new thing. Lines need to be drawn about what is in the
project and what isn't.

Bringing a project like that to completion is going to involve a lot of
community involvement. And that's the thing students are historically
the worst at it. I think it's _also_ the most valuable thing they can
learn. But I think it doesn't make for a very gentle introduction to
open source.

Again, just my two cents. I don't want to dissuade anybody from this
project in particular, or this style of project. I'm more trying to
bring up discussion on how and why projects fail.

-Peff

Re: Google Summer of Code 2013 (GSoC13)

[Jeff King]

On Tue, Feb 19, 2013 at 02:14:54AM +0530, Ramkumar Ramachandra wrote:

> >  - 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
> 
> Overkill.  I just symlink to bin-wrapper/git from a place high up in
> my $PATH.  If anything, we should be making it easier for ourselves to
> run different versions of git right from $HOME, much like rbenv.
> System-wide installs are taken care of by the distribution package
> managers, and I doubt they need any help from us.

This is not related to GSoC anymore, but I think handling multiple
versions is already pretty easy. You can just install to
"$HOME/local/git/$TAGNAME" or similar, and then symlink the "bin/git"
binary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8). Git
already takes care of the messy bits, like making sure sub-programs are
invoked from the same git version.

I already do this automagically with this script:

  https://github.com/peff/git/blob/meta/install/prefix

I just set "prefix" in the Makefile based on the script, and when I
"make install" tags or topic branches, they go to the right place (and
the "links" script in the same directory maintains the symlinks for me).

I never bothered to even submit those scripts to contrib, because I
figured they were so specific to my setup, and to keeping dozens of git
versions around (when debugging, it's nice to be able to check an old
version's behavior without even having to build it).

Of course that has nothing to do with Jonathan's proposal. I do agree
that it is pretty straightforward to just put $BUILD_DIR/bin-wrappers in
your PATH and be done. I guess that doesn't cover manpages, though (but
Real Programmers just read the source anyway, right?).

-Peff

Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))

[Jonathan Nieder]

Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:

>>  - cross-compilable git
>
> Why, exactly?  Git for embedded devices?

My personal motivation would be building Git for Windows while
spending as little time on Windows as possible.  People deploying git
to 32-bit x86, 64-bit x86, and ARM (think "ARM laptops") might also
find it handy.

>>  - incorporation of the cgit web interface, or formalizing a subset of
>>    libgit.a to export as a stable library to it
>
> I didn't understand this: you want cgit in-tree?

Yes, or a stable API that cgit out-of-tree can use.

>>  - 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
>
> I can't see a roadmap for gradually phasing out `rebase -i` as more
> and more of its functionality is built into the sequencer.

It's a break-the-world thing.  "rebase -i --experimental".

[...]
> For usable svn remote helper, the major TODO is a git -> svn bridge.

There are other major TODOs, too.

[...]
>>  - drag-and-drop cherry-pick in gitk
>
> You expect someone to write Tcl/Tk today?

Sure, why not?  Tcl is not actually too unpleasant of a language.

Maybe it has a prerequisite, though:

 - "modular gitk" (splitting gitk into digestible pieces)

[...]
>>  - assimilating the distro builds:
[...]
> Overkill.

My itch is that it would let me send packaging patches to the list
and get the usual high-quality feedback.  Oh well. ;-)

[...]
>>  - 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
>
> I personally don't care for notes much, because I can't see practical
> usecases.

Are you sure that's not because of the poor current state of
collaborative notes editing?

Some example use cases:

 - marking regressions discovered later, to warn people bisecting or
   cherry-picking

 - matching up to corresponding commits in another repository

 - link to corresponding mailing list discussion, blog post, or
   related patches

 - a wiki-like document storing review comments

 - marking which CVE this fixes, once the CVE number has been
   allocated

 - "a tour of the project" for new contributors, using explanatory
   notes that end with a mention the next commit to look at

I'm not married to the current implementation, but I think the basic
idea of "git notes" is a promising feature that could use some polish.

Jonathan

Re: Google Summer of Code 2013 (GSoC13)

[Jeff King]

On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote:

> Take what I'm about to say with a pinch of salt, because I've never mentored.
> 
> Mentors often don't provide much technical assistance: students should
> just post to the list with queries, or ask on #git-devel.  Mentors
> serve a different purpose; their primary responsibility, in my
> opinion, is to teach the student a sustainable productive workflow.
> This means: profiling them to figure out where they're losing out.  Do
> they have the habit of:
> - posting to the list regularly?
> - CC'ing the right people?
> - iterating quickly after reviews?
> - using gdb efficiently to quickly understand parts?
> - using git efficiently for the rebase/ patch workflow?

I think you are spot-on. Those are the things that students need to
learn to do, and what mentors should be pushing them towards. But it
seems like we have the same problems with it year after year, and I know
mentors have worked on it. I'm not sure where the problem is.

> > I very much agree with you here. One problem is that those smaller
> > projects often do not sound as grand or as interesting, and so students
> > do not propose them. We have to work with the applicants we get.
> 
> We have to post well-crafted proposals like this to pique their interest.

True. I think we can bear some of the blame in the proposal writing. But
if you look at the applications each year, they tend to cluster around
one or two projects, and most projects get no hits at all. It could be
because they're badly written. But I think it is also that they are not
in areas that are as flashy (and the flashiness often correlates with
complexity).

> No, I'm against using the GitHub Wiki for neutrality reasons.

Fair enough. I have the same reservations.

> There is one easy way to fight spam: don't expose a web-based editing
> interface at all.  It's mainly going to be maintained by the
> community, and we're all much more comfortable in our editors and git.
> We can give the regulars direct commit access and ask the rest to
> submit pull requests.  Make it cost pennies, so any of us can easily
> afford it: just a cheap domain, DNS, and static HTML hosting.

I'd be totally fine with that. You'd need to pick a static generator
framework (I don't think it is a good idea for everybody to be writing
raw html). I suspect kernel.org would be happy to host the static pages,
but if not, GitHub can pick up the hosting tab (and we could probably do
it as a subdomain under git-scm.com, too, if people want).

-Peff

Re: Google Summer of Code 2013 (GSoC13)

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> [corrected David Barr's email address]
>
> Jeff King wrote:
>> And I do not want to blame the students here (some of whom are on the cc
>> list :) ). They are certainly under no obligation to stick around after
>> GSoC ends, and I know they have many demands on their time. But I am
>> also thinking about what Git wants to get out of GSoC (and to my mind,
>> the most important thing is contributors).
>>
>> As far as merged code, I think part of the problem is that git is fairly
>> mature at this point. The most interesting projects are of a bigger
>> scope than a student with no experience in the code base can do in a
>> summer project. Maybe that means we need to do a better job of breaking
>> projects down into reasonably sized sub-components. Or maybe it means
>> the project is hitting a point of diminishing returns for GSoC. I don't
>> know.
>
> Also, we need more projects that will scratch everyday itches.  A
> collection of related tiny features might not be a bad idea.  Often,
> we risk erring on the side of too-big-for-one-summer when it comes to
> specifying projects.  What's the harm of including something estimated
> to take 80% of a summer?

I think the real issue is everybody in the GSoC mentor candidate
pool grossly underestimates the scope of suggested projects, does
not encourage students to send early drafts to the public from the
beginning, and perhaps overestimates the ability of total beginners.
After seeing my "index-thing is too big in scope" warning repeatedly
ignored for the last year's GSoC, I am not very hopeful unless the
attitude towards GSoC and its students drastically changes on our
mentors' end.

We have solicited "suggested projects" entries via wiki in the past,
letting anybody to put anything there, and I think that was a major
source of our past failures.  The practice lets irresponsive people
who think they know what they are talking about to place unrealistic
pie-in-the-sky there.  I wonder if we can somehow come up with a way
to limit them to realisitic ones in a sane way.  One possibility may
be to require the proposer to already have an 80% answer, not to be
shared with students.  A project that a GSoC student who is not
familiar with our codebase and culture (e.g. our no regressions
policy and requiring solid transition plan for disruptive changes)
is expected to finish in a summer should not be bigger than what a
mentor familiar with our project can do a rough outline design and
implementation as a two-weekend hack at most, I think.

Such a requirement on the proposer's end may be a reasonable sanity
check to make sure we do not suggest sure-to-fail projects to the
students.

It is ironic that I have to point out that the best "let's get
students exposed to the OSS process using Git community's reviewing
bandwidth" last year from my point of view happened outside the
GSoC.  Matthieu's school projects were not structured to the GSoC
standard (they assigned multiple students working together on each
topic), but the size of the projects seemed more manageable.  It was
a joy to work with these students during the term of the project. We
had a meaningful number of review iterations, unlike a typical GSoC
project where a student and her mentors sit in a dark cave for a
long time, send out the first draft too late, and the participant do
not get enough time to do meaningful iterations of reviews (it was
also a huge plus from our project's point of view that there were
even responsible post-program follow up to complete the unfinished
bits).

Re: Google Summer of Code 2013 (GSoC13)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> This is not related to GSoC anymore, but I think handling multiple
> versions is already pretty easy. You can just install to
> "$HOME/local/git/$TAGNAME" or similar, and then symlink the "bin/git"
> binary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8). Git
> already takes care of the messy bits, like making sure sub-programs are
> invoked from the same git version.
>
> I already do this automagically with this script:
>
>   https://github.com/peff/git/blob/meta/install/prefix
>
> I just set "prefix" in the Makefile based on the script, and when I
> "make install" tags or topic branches, they go to the right place (and
> the "links" script in the same directory maintains the symlinks for me).
>
> I never bothered to even submit those scripts to contrib, because I
> figured they were so specific to my setup, and to keeping dozens of git
> versions around (when debugging, it's nice to be able to check an old
> version's behavior without even having to build it).

Yeah, I have been using the Make (in the todo branch, to be checked
out in Meta/ subdirectory of the working tree) script for exactly
this.  After tagging a release, I'd do

	git checkout -B snap v1.8.1.3
        Meta/Make install install-doc

to install them in $inst_prefix/git-snap-v1.8.1.3.  A "rungit"
script can then be used like:

	rungit v1.7.0 checkout blah

-- rungit script -- >8 -- rungit script --
#!/bin/sh
# Run various vintage of git

variant="${0##*/}" &&
: ${RUNGIT_BASE=$HOME/g/$(getarch)} &&
case "$variant" in
rungit)
	case $# in 
	0)
		echo >&2 "which version?"
		exit 1
		;;
	esac
	variant=$1
	shift
	;;
esac &&
case "$variant" in
-l)
	for d in "$RUNGIT_BASE/"git-*/bin/git
	do
		d=$(basename ${d%/bin/git})
		d=${d#git-}
		d=${d#snap-}
		echo "$d"
	done
	exit
	;;
git-*)
	variant=${variant#git-} ;;
v[0-9]*)
	variant=snap-$variant ;;
esac &&
d="$RUNGIT_BASE/git-$variant" &&
if test -f "$d/bin/git"
then
	exec "$d/bin/git" "$@"
else
	echo >&2 "$variant: No such variant for $a"
	exit 1
fi

Re: Google Summer of Code 2013 (GSoC13)

[Jonathan Nieder]

Jeff King wrote:
> On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote:

>> Some potential projects (unfiltered --- please take them with a grain
>> of salt):
>> [...]
>>  - 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
>
> I know you said a grain of salt, so please don't feel like I'm beating
> up on your idea. I'm picking this one because I think it has some
> characteristics of projects that have not gone well in the past, so it's
> a good illustrative example.
>
> IMHO, this is the type of project that is likely to fail, because most
> of the work is not technical at all, but political. Changing the default
> refspecs is a few lines of code. But the hard part is figuring out where
> they should go, the implications of doing so, and how people are going
> to react.

I think I agree, if by "likely to fail" you mean "easy to underestimate
the difficulty of".  I actually think it would be a pretty good summer
student project, for a few related reasons:

 * Years of evidence show it is a hard problem.  It would be a good
   notch in the belt of whoever takes the project on.

 * It does not require a deep understanding of git internals.  A good
   familiarity with the git user interface, on the other hand, would
   be essential, but I hope that is becoming more common among
   students these days.

 * It requires good taste and design sense, which are something it
   would be nice to cultivate and encourage.

 * The change is necessary and the satisfaction of helping a student
   through the process might be enough to finally get it done.

 * If an amazing candidate finishes the "make collaboration possible"
   task early, there's plenty of valuable, interesting, and technically
   complicated follow-on work regarding the related "share some notes
   while hiding others" to fill the rest of the summer.

The code change for the most basic subset of "make collaboration
possible" would presumably be a changed refspec, some documentation,
and some tests.  On top of that there is presumably some automagic
incorporation of upstream notes to be cooked into "git pull".  Some
better conflict-resolution magic.  Example scripts to generate notes.
Support for the format-patch / am workflow.  gitweb support for
showing notes.

It's a good example of when it's useful to not be afraid of failing to
please everybody and just get something done.

I also can't think of any examples of such technically straightforward
student projects being tried before.

Jonathan

Re: Google Summer of Code 2013 (GSoC13)

[Duy Nguyen]

On Tue, Feb 19, 2013 at 12:23 AM, Thomas Rast <trast@inf.ethz.ch> wrote:
> * Naturally that ideas page is a bit stale now, and three projects
>   shorter.  Please propose new ideas and refresh or delete the old ones!
>   In particular some projects spawned long discussions on the list, and
>   the results of those discussions should be integrated to avoid deja
>   vus.

A proposal from what I've been involved lately: inotify support to
eliminate lstat and readdir syscalls. The scope may be small. But we
could aim to get it merged in master or at least next by the end of
GSoC. Or extend to another platform besides Linux, it helps ensure we
have good abstraction. My free time goes up and down unexpectedly, not
sure if I can commit to be a mentor. But I'm definitely interested and
will support whenever I can.
-- 
Duy

Re: Potential GSoC13 projects (Re: Google Summer of Code 2013 (GSoC13))

[Duy Nguyen]

On Tue, Feb 19, 2013 at 4:11 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ramkumar Ramachandra wrote:
>> Jonathan Nieder wrote:
>
>>>  - cross-compilable git
>>
>> Why, exactly?  Git for embedded devices?
>
> My personal motivation would be building Git for Windows while
> spending as little time on Windows as possible.  People deploying git
> to 32-bit x86, 64-bit x86, and ARM (think "ARM laptops") might also
> find it handy.

I did something like that long ago (for cross compiling Windows).
Although I eventually gave up on the Windows front as I was too lazy
to test on Windows :) (and Wine by that time was not good enough) I
think some of my patches are in the archive. Will dig them up.
-- 
Duy

Re: Google Summer of Code 2013 (GSoC13)

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> [corrected David Barr's email address]
>>
>> Jeff King wrote:
>>> And I do not want to blame the students here (some of whom are on the cc
>>> list :) ). They are certainly under no obligation to stick around after
>>> GSoC ends, and I know they have many demands on their time. But I am
>>> also thinking about what Git wants to get out of GSoC (and to my mind,
>>> the most important thing is contributors).
>>>
>>> As far as merged code, I think part of the problem is that git is fairly
>>> mature at this point. The most interesting projects are of a bigger
>>> scope than a student with no experience in the code base can do in a
>>> summer project. Maybe that means we need to do a better job of breaking
>>> projects down into reasonably sized sub-components. Or maybe it means
>>> the project is hitting a point of diminishing returns for GSoC. I don't
>>> know.
>>
>> Also, we need more projects that will scratch everyday itches.  A
>> collection of related tiny features might not be a bad idea.  Often,
>> we risk erring on the side of too-big-for-one-summer when it comes to
>> specifying projects.  What's the harm of including something estimated
>> to take 80% of a summer?
>
> I think the real issue is everybody in the GSoC mentor candidate
> pool grossly underestimates the scope of suggested projects, does
> not encourage students to send early drafts to the public from the
> beginning, and perhaps overestimates the ability of total beginners.
> After seeing my "index-thing is too big in scope" warning repeatedly
> ignored for the last year's GSoC, I am not very hopeful unless the
> attitude towards GSoC and its students drastically changes on our
> mentors' end.

The short undiplomatic version of that is that our mentors suck (I'm
not pointing fingers, but that's what I infer from failing projects).
In my opinion, there is no point putting up proposed mentors for
projects in advance: ideal mentors are people who are interested in
the students, more than the project proposals.

> We have solicited "suggested projects" entries via wiki in the past,
> letting anybody to put anything there, and I think that was a major
> source of our past failures.  The practice lets irresponsive people
> who think they know what they are talking about to place unrealistic
> pie-in-the-sky there.  I wonder if we can somehow come up with a way
> to limit them to realisitic ones in a sane way.  One possibility may
> be to require the proposer to already have an 80% answer, not to be
> shared with students.  A project that a GSoC student who is not
> familiar with our codebase and culture (e.g. our no regressions
> policy and requiring solid transition plan for disruptive changes)
> is expected to finish in a summer should not be bigger than what a
> mentor familiar with our project can do a rough outline design and
> implementation as a two-weekend hack at most, I think.

The Wiki is often polluted with arbitrary, useless, unrealistic
projects.  We expect students to pick up from a small writeup on the
Wiki and come up with everything else, and I think this is a mistake.
Further, I think burdening one pre-chosen mentor with all the
groundwork is a terrible idea.

I propose that we have one thread for every proposal where we can all
discuss the implementation outline- this will serve as authoritative
source of information for students, and for picking mentors (the
people who contribute most to the discussion).  Students should be
matched with mentors on an individual basis.

> Such a requirement on the proposer's end may be a reasonable sanity
> check to make sure we do not suggest sure-to-fail projects to the
> students.

The discussion thread will automatically tell us which projects are
badly thought-out and unrealistic.

Re: Google Summer of Code 2013 (GSoC13)

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

> The short undiplomatic version of that is that our mentors suck (I'm
> not pointing fingers, but that's what I infer from failing projects).

Hold on a second.  I'm not remembering such a grim outcome with 100%
failure from prior summers of code as you're describing.  Before I
start beating myself up, I guess I'd like a little more information
--- is there some specific project or statistic that you're thinking
of that brings you to that conclusion?

[...]
> I propose that we have one thread for every proposal where we can all
> discuss the implementation outline- this will serve as authoritative
> source of information for students, and for picking mentors (the
> people who contribute most to the discussion).  Students should be
> matched with mentors on an individual basis.

How is that different from what happened in previous summers where
students made proposals, received feedback, and were accepted and
matched to mentors or rejected based on how the discussion went?

Jonathan

Re: Google Summer of Code 2013 (GSoC13)

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Junio C Hamano wrote:
> ...
>> I think the real issue is everybody in the GSoC mentor candidate
>> pool grossly underestimates the scope of suggested projects, does
>> not encourage students to send early drafts to the public from the
>> beginning, and perhaps overestimates the ability of total beginners.
>> After seeing my "index-thing is too big in scope" warning repeatedly
>> ignored for the last year's GSoC, I am not very hopeful unless the
>> attitude towards GSoC and its students drastically changes on our
>> mentors' end.
>
> The short undiplomatic version of that is that our mentors suck (I'm
> not pointing fingers, but that's what I infer from failing projects).

I was conflating between people who add "suggested project" and who
act as mentors.  I do not think mentors are primarily responsible
for bad suggested projects.

Our mentors may be wonderful but I do not have enough evidence to
judge either way.  They are mostly student-facing and I as a
bystander to GSoC process didn't see much of their involvement in
their students' work---maybe that is how it is supposed to work,
maybe not.  The only failing of them observable from my point of
view was that we repeatedly saw the initial round of patches come
very late.

But my complaints were primarily about those sure-to-fail project
suggestions.

> I propose that we have one thread for every proposal where we can all
> discuss the implementation outline- this will serve as authoritative
> source of information for students, and for picking mentors (the
> people who contribute most to the discussion).  Students should be
> matched with mentors on an individual basis.

You are being unreasonable and/or unrealistic. A topic that needs a
large discussion thread to pre-discuss design and outline by many
existing members of community and mentor candidates is a sure sign
that the topic is too big for a beginner. A topic that needs only a
small enough discussion thread on the other hand will come to a
polished conclusion before even the student shows up.  

This is exactly why I suggested "doable as a private, at most
two-weekend hack by an experienced" as a quick and dirty way to
measure the size of a project.

Re: Google Summer of Code 2013 (GSoC13)

[Ramkumar Ramachandra]

Thomas Rast wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
> [...]
>>>> On a related note, I don't like our Wiki.  It's down half the time,
>>>> and it's very badly maintained.  I want to write content for our Wiki
>>>> from the comfort of my editor, with version control aiding me.  And I
>>>> can't stand archaic WikiText.
>>>
>>> Agreed on all of those points. Putting the Wiki on GitHub fixes that.
>>> But it means contributors need to have a GitHub account. On the other
>>> hand, I think kernel.org wiki contributors need an account these days?
>>> And GitHub is putting some active effort into finding and killing spammy
>>> accounts, which might keep wiki spam down (I do not pay too much
>>> attention to those efforts, but on kernel.org, it is mostly up to the
>>> Git community to do it ourselves).
>>
>> No, I'm against using the GitHub Wiki for neutrality reasons.  There
>> is one easy way to fight spam: don't expose a web-based editing
>> interface at all.  It's mainly going to be maintained by the
>> community, and we're all much more comfortable in our editors and git.
>>  We can give the regulars direct commit access and ask the rest to
>> submit pull requests.  Make it cost pennies, so any of us can easily
>> afford it: just a cheap domain, DNS, and static HTML hosting.
>
> I suppose since github's wiki system (gollum) is open source [1] it
> wouldn't be too hard to set up another instance somewhere.  Bonus points
> for importing all the old data in mediawiki format first, which is also
> apparently supported.

Yes, I am aware.  However, I don't think gollum fits our purposes
well: we really don't need much more than plain text.
What do you want to import?  We can copy out the text from the
previous GSoC pages, but most of the other pages are filled with
ancient junk.  We don't want a museum: we want a clean Wiki with
crisp, clean up-to-date information.

> But that just shifts the point of failure from the entire github team to
> one or two people who end up administering the server.

... which is the entire problem.  We don't want to "administer"
things.  We're programmers who're competent at writing plain text and
maintaining git repositories, so let's stick to doing that; I'm
pushing for static HTML hosting for exactly this reason: there is
nothing to "administer", no security exploits, no unexpected
breakages.  It also reflects our community's affinity for simplicity.

> Perhaps a better solution would be to ask Scott or Peff to create a
> gollum instance under git-scm.com, which they're already hosting?

Failing that, just a CNAME entry for "wiki" under git-scm.com would
suffice.  What does static HTML hosting cost anyway?

> (It
> seems people got over *that* neutrality issue quickly enough.)

There's a big difference between having git-scm.com as our official
website, and hosting our official Wiki on
https://github.com/git/git/wiki.  Although it is built by people
working in GitHub, with its sources in github.com/github/gitscm-next,
it makes no effort to reference GitHub directly.

Ofcourse, there are many things I dislike about the website, and would
have preferred a community-built one.  Unfortunately, building a
website involves doing design work that we programmers are incompetent
at.  So, I think of it as a practical compromise that we have to live
with.

Re: Google Summer of Code 2013 (GSoC13)

[Ramkumar Ramachandra]

Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> The short undiplomatic version of that is that our mentors suck (I'm
>> not pointing fingers, but that's what I infer from failing projects).
>
> Hold on a second.  I'm not remembering such a grim outcome with 100%
> failure from prior summers of code as you're describing.  Before I
> start beating myself up, I guess I'd like a little more information
> --- is there some specific project or statistic that you're thinking
> of that brings you to that conclusion?

In retrospect, I might have been unnecessarily harsh there.

One of the main measures of a mentor's success, in my opinion, is
having his student stick around after the Summer of Code: the mentor
is the student's primary link to the community.  There have been 4~5
students every year, times 6 years (is that how long we've been
participating?).  How many of those students have felt part of the
community?

Re: Google Summer of Code 2013 (GSoC13)

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Junio C Hamano wrote:
>> ...
>>> I think the real issue is everybody in the GSoC mentor candidate
>>> pool grossly underestimates the scope of suggested projects, does
>>> not encourage students to send early drafts to the public from the
>>> beginning, and perhaps overestimates the ability of total beginners.
>>> After seeing my "index-thing is too big in scope" warning repeatedly
>>> ignored for the last year's GSoC, I am not very hopeful unless the
>>> attitude towards GSoC and its students drastically changes on our
>>> mentors' end.
>>
>> The short undiplomatic version of that is that our mentors suck (I'm
>> not pointing fingers, but that's what I infer from failing projects).
>
> I was conflating between people who add "suggested project" and who
> act as mentors.  I do not think mentors are primarily responsible
> for bad suggested projects.

Why do mentors pick badly sketched-out projects to mentor?  They're
free to pick anything they want/ propose what they want.

> Our mentors may be wonderful but I do not have enough evidence to
> judge either way.  They are mostly student-facing and I as a
> bystander to GSoC process didn't see much of their involvement in
> their students' work---maybe that is how it is supposed to work,
> maybe not.  The only failing of them observable from my point of
> view was that we repeatedly saw the initial round of patches come
> very late.

Ideally, the initial round of patches should come in well before the
GSoC even starts, I think (the initial round might just be doing some
minor surrounding work though).

>> I propose that we have one thread for every proposal where we can all
>> discuss the implementation outline- this will serve as authoritative
>> source of information for students, and for picking mentors (the
>> people who contribute most to the discussion).  Students should be
>> matched with mentors on an individual basis.
>
> You are being unreasonable and/or unrealistic. A topic that needs a
> large discussion thread to pre-discuss design and outline by many
> existing members of community and mentor candidates is a sure sign
> that the topic is too big for a beginner. A topic that needs only a
> small enough discussion thread on the other hand will come to a
> polished conclusion before even the student shows up.

I that case, projects like inotify support that Duy suggested in a
nearby thread are not realistic candidates.  No, I wouldn't like huge
discussion threads on each proposal either: but a ~10 email thread
with everyone's thoughts on it would be useful, I think.  If the size
of the thread exceeds a certain threshold, the project is deemed
un-doable automatically.

> This is exactly why I suggested "doable as a private, at most
> two-weekend hack by an experienced" as a quick and dirty way to
> measure the size of a project.

Yes, that's a good measure.

Re: Google Summer of Code 2013 (GSoC13)

[Thomas Rast]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>>
>>> The short undiplomatic version of that is that our mentors suck (I'm
>>> not pointing fingers, but that's what I infer from failing projects).
>>
>> Hold on a second.  I'm not remembering such a grim outcome with 100%
>> failure from prior summers of code as you're describing.  Before I
>> start beating myself up, I guess I'd like a little more information
>> --- is there some specific project or statistic that you're thinking
>> of that brings you to that conclusion?
>
> In retrospect, I might have been unnecessarily harsh there.
>
> One of the main measures of a mentor's success, in my opinion, is
> having his student stick around after the Summer of Code: the mentor
> is the student's primary link to the community.  There have been 4~5
> students every year, times 6 years (is that how long we've been
> participating?).  How many of those students have felt part of the
> community?

In defense of Thomas, whose project was mentioned earlier as a prime
example of something that is "too big":

He's in fact still working on the index-API angle, as part of a thesis
at university.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Google Summer of Code 2013 (GSoC13)

[Ramkumar Ramachandra]

Jeff King wrote:
> On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote:
>
>> Take what I'm about to say with a pinch of salt, because I've never mentored.
>>
>> Mentors often don't provide much technical assistance: students should
>> just post to the list with queries, or ask on #git-devel.  Mentors
>> serve a different purpose; their primary responsibility, in my
>> opinion, is to teach the student a sustainable productive workflow.
>> This means: profiling them to figure out where they're losing out.  Do
>> they have the habit of:
>> - posting to the list regularly?
>> - CC'ing the right people?
>> - iterating quickly after reviews?
>> - using gdb efficiently to quickly understand parts?
>> - using git efficiently for the rebase/ patch workflow?
>
> I think you are spot-on. Those are the things that students need to
> learn to do, and what mentors should be pushing them towards. But it
> seems like we have the same problems with it year after year, and I know
> mentors have worked on it. I'm not sure where the problem is.

I essentially have a couple of suggestions:
- Be more thorough about discussing proposals; pick mentors from those
who are deeply involved in the discussion, and are interested in the
student.
- Increase the visibility of every GSoC project in the community.
Like I suggested earlier, a set of GSoC branches in-tree would be a
great start: it's easy to go through the `log`, and tell if the
student has been idle for a while.  We can put up links to the GitHub
graphs for each of these branches.

>> > I very much agree with you here. One problem is that those smaller
>> > projects often do not sound as grand or as interesting, and so students
>> > do not propose them. We have to work with the applicants we get.
>>
>> We have to post well-crafted proposals like this to pique their interest.
>
> True. I think we can bear some of the blame in the proposal writing. But
> if you look at the applications each year, they tend to cluster around
> one or two projects, and most projects get no hits at all. It could be
> because they're badly written. But I think it is also that they are not
> in areas that are as flashy (and the flashiness often correlates with
> complexity).

We need to collaborate on proposal writing, I think (which is why I
suggested one-thread-per-proposal in a different email).  In the past,
it has mostly been one person writing the entire thing.

>> There is one easy way to fight spam: don't expose a web-based editing
>> interface at all.  It's mainly going to be maintained by the
>> community, and we're all much more comfortable in our editors and git.
>> We can give the regulars direct commit access and ask the rest to
>> submit pull requests.  Make it cost pennies, so any of us can easily
>> afford it: just a cheap domain, DNS, and static HTML hosting.
>
> I'd be totally fine with that. You'd need to pick a static generator
> framework (I don't think it is a good idea for everybody to be writing
> raw html). I suspect kernel.org would be happy to host the static pages,
> but if not, GitHub can pick up the hosting tab (and we could probably do
> it as a subdomain under git-scm.com, too, if people want).

Ofcourse.  Nobody wants to write raw HTML.  Additionally, I'd love it
if we could post new posts via email, since we already have the habit
of writing emails.

Re: Google Summer of Code 2013 (GSoC13)

[Junio C Hamano]

Thomas Rast <trast@inf.ethz.ch> writes:

> In defense of Thomas, whose project was mentioned earlier as a prime
> example of something that is "too big":
>
> He's in fact still working on the index-API angle, as part of a thesis
> at university.

That is probably a good indicator that it was too big for a summer
student.  It also is good to hear that the topic is being looked at
;-).

Re: Google Summer of Code 2013 (GSoC13)

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

>> I was conflating between people who add "suggested project" and who
>> act as mentors.  I do not think mentors are primarily responsible
>> for bad suggested projects.
>
> Why do mentors pick badly sketched-out projects to mentor?  They're
> free to pick anything they want/ propose what they want.

I've had an impression that these Wiki entries were written by
people with names of mentors (who are different from the proposers)
already assigned to them, and if an unfortunate student picked an
unrealistic one, these mentor candidates were too nice to push back
and decline, saying "it is unrealistic", leaving the student and
proposal without any mentor.

Re: Google Summer of Code 2013 (GSoC13)

[Thomas Rast]

Junio C Hamano <gitster@pobox.com> writes:

> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> In defense of Thomas, whose project was mentioned earlier as a prime
>> example of something that is "too big":
>>
>> He's in fact still working on the index-API angle, as part of a thesis
>> at university.
>
> That is probably a good indicator that it was too big for a summer
> student.  It also is good to hear that the topic is being looked at
> ;-).

Not really: the API angle was never part of the proposal.  The timeline
was [1 if you have access]:

  24/04 - 01/05: Document the new index format.
  02/05 - 11/05: Create a converter of the old index format to the new format.
  12/05 - 18/06: Parse the index from disk to the current in-memory format. The
  old index format shall still be readable.
  19/06 - 09/07: Implement the re-reading of a single record, if the crc32 doesn't
  match (Meaning the record has been changed under the reader).
  10/07 - 21/07:  Map the current internal structure to the new index format.
  22/07 - 31/07: Change the current in-memory structure to keep track of the
  changed files.
  01/08 - 13/08: Write the index to disk in both the old and the new format
  depending on the choice of the user and make sure only the changed parts are
  really written to disk in the new format.
  11/08 - 13/08: Test the new index and profile the gains compared to the old
  format.
  /* Development work will be a bit slower from 18/06 to 21/07 because at my
   * University there are exams in this period. I probably will only be able to
   * work half the hours. I'll be back up to full speed after that. */

I think this case is somewhat symptomatic for one possible cause of
dragged-out non-inclusions _after_ GSoC: there's a certain scope creep
caused by striving for the perfect, long-term maintainable code.

The solution IMHO is to _both_ recognize such possibilities for scope
creep, and cut down the proposals to a size where a student has a
reasonable chance of achieving the code quality required for inclusion.

(The latter option has been mentioned a few times, but I wanted to make
people aware that the scope creep is happening, too.)


Footnotes: 
[1]  http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/tgummerer/1

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Google Summer of Code 2013 (GSoC13)

[Christian Couder]

On Mon, Feb 18, 2013 at 9:02 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 18.02.2013 20:34, schrieb Jonathan Nieder:
>> 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).
>
> That's my experience too. Also I think it really makes sense to have a
> co-mentor so you can balance the load a bit.
>
>> I'd be happy to help on a project with 1 or 2 co-mentors.
>
> Same here.

I am ok to be mentor or co-mentor.

Thanks,
Christian.

Re: Google Summer of Code 2013 (GSoC13)

[Shawn Pearce]

On Mon, Feb 18, 2013 at 9:42 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:
>
>> * We need an org admin.  AFAIK this was done by Peff and Shawn in
>>   tandem last year.  Would you do it again?
>
> 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.

This.

I actually think Git should take a year off from GSoC and not
participate. Consequently I will not be volunteering as backup org
admin.

Git has been involved since 2007. In all of that time we have had very
few student projects merge successfully into their upstream project
(e.g. git.git, JGit or libgit2) before the end of GSoC. Even fewer
students have stuck around and remained active contributors. When I
look at the amount of effort we contributors put into GSoC, I think we
are misusing our limited time and resources. The intention of the GSoC
program is to grow new open source developers, and increase our
community of contributors. Somehow I think Git is falling well short
of its potential here. This is especially true if you compare Git's
GSoC program to some other equally long-running GSoC programs.

> And I do not want to blame the students here (some of whom are on the cc
> list :) ). They are certainly under no obligation to stick around after
> GSoC ends, and I know they have many demands on their time. But I am
> also thinking about what Git wants to get out of GSoC (and to my mind,
> the most important thing is contributors).

I agree, our students have been pretty terrific. I think the
shortcomings in our GSoC program are on the mentoring side. Our
program has not really had much success with keeping students active
and engaged post GSoC. I see that primarily as a mentoring failure.
And its one we keep repeating each year.

> As far as merged code, I think part of the problem is that git is fairly
> mature at this point. The most interesting projects are of a bigger
> scope than a student with no experience in the code base can do in a
> summer project. Maybe that means we need to do a better job of breaking
> projects down into reasonably sized sub-components. Or maybe it means
> the project is hitting a point of diminishing returns for GSoC. I don't
> know.

Let me repeat myself. I think our GSoC program has plenty of room for
improvement on the mentoring side. Project scope and size is one of
our most common failure modes. Resumable clone keeps winding up on the
GSoC project idea list. Nobody who knows what they are talking about
has any idea how to approach this feature[1]. Suggesting it to a GSoC
student is just irresponsible[2].

I don't think Git's maturity is a road block for successful GSoC
projects. Peff's toy to insert Lua so `git log` could do fancy
formatting is an interesting one. I suspect there are still fun
archeology sorts of projects that could further improve the type of
data we can mine through log and blame. But touching the core file
formats on disk or the wire protocol is probably far too large for a
GSoC project.

[1] Android's "repo" tool and its /clone.bundle hack on HTTP
transports might work. Peff has talked about putting this into Git
itself one day. Maybe. But its still full of a ton of shortcomings and
somewhat hated by those that have to build the bundles and manage the
server infrastructure. So its probably still outside of the scope of a
successful GSoC project.

[2] I recognize and accept my share of blame for putting it on the
list a few times.

> There are a few counterpoints I can think of:
>
>   - Even though not all projects are winners, _some_ are. I see Carlos
>     and Ram on the cc list, two people who started as GSoC students and
>     stuck around.

I think these interesting cases like Carlos and Ram are places where
the student was able to succeed almost despite our mentoring program.
I am very glad they did.

>   - There is also the angle that even if _Git_ doesn't benefit directly
>     from people sticking around, those people may float into other open
>     source projects and work on them. Which makes the world a better
>     place on the whole.

Yes, sure, OK. But if Git doesn't participate in GSoC this year
another org will, and this same benefit will still be had by the
greater open source community.

Re: Google Summer of Code 2013 (GSoC13)

[Christian Couder]

Hi,

On Wed, Feb 20, 2013 at 7:50 AM, Shawn Pearce <spearce@spearce.org> wrote:
> On Mon, Feb 18, 2013 at 9:42 AM, Jeff King <peff@peff.net> wrote:
>> On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:
>>
>>> * We need an org admin.  AFAIK this was done by Peff and Shawn in
>>>   tandem last year.  Would you do it again?
>>
>> 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.
>
> This.

I think it is ok if the code doesn't make a big impact in the code
base and it is ok too if the participants don't stuck around.
Of course I would love both of these things to happen, but we have to
be realistic and just stop expecting it.

> I actually think Git should take a year off from GSoC and not
> participate. Consequently I will not be volunteering as backup org
> admin.
>
> Git has been involved since 2007. In all of that time we have had very
> few student projects merge successfully into their upstream project
> (e.g. git.git, JGit or libgit2) before the end of GSoC. Even fewer
> students have stuck around and remained active contributors. When I
> look at the amount of effort we contributors put into GSoC, I think we
> are misusing our limited time and resources.

I don't think so, at least not for me. I feel happy to mentor or
co-mentor GSoC student and I don't think I would work much more on git
these days if git was not participating to the GSoC.

> The intention of the GSoC
> program is to grow new open source developers, and increase our
> community of contributors. Somehow I think Git is falling well short
> of its potential here. This is especially true if you compare Git's
> GSoC program to some other equally long-running GSoC programs.
>
>> And I do not want to blame the students here (some of whom are on the cc
>> list :) ). They are certainly under no obligation to stick around after
>> GSoC ends, and I know they have many demands on their time. But I am
>> also thinking about what Git wants to get out of GSoC (and to my mind,
>> the most important thing is contributors).
>
> I agree, our students have been pretty terrific. I think the
> shortcomings in our GSoC program are on the mentoring side. Our
> program has not really had much success with keeping students active
> and engaged post GSoC. I see that primarily as a mentoring failure.
> And its one we keep repeating each year.

I don't quite agree with this. My experience has been the following:

- 2008: the student I co-mentored did pretty well though he didn't
send to the list his patch series early enough.
So there was some mentoring failure, but anyway the student stuck
around for 9 months and managed to get 53 commits merged.

- 2009: if I remember well, it was decided to have only 2 GSoC student
that year, and that 5 people would co-mentor both of them together.
One of the student did nearly nothing. The other one sent his patch
series too late to the list. My opinion is that he relied too much on
the people mentoring him and he worked on something that was difficult
to merge.

- 2010: the student I co-mentored stopped working 3 weeks before the
mid-term evaluation despite some warnings from me and Peff, and he had
not been doing much a few weeks before that, so we decided to fail him
at the mid term evaluation.

- 2011: I was lucky to mentor Ram who did well and is still around.

So my opinion is that we have some students who are just not doing
enough (2 out of 5).
Then we have some good students, 2 out of 5 who could sometimes do
better if we insisted more on submitting earlier to the mailing list.
And we have a few students (1 out of 5) who work difficult to merge
projects and who could do better if we insisted more on submitting
earlier to the mailing list.

So my conclusions are:
- it's quite often going well or well enough
- when it's not going well often the student is responsible
- yes, we could improve mentoring by providing better projects and
insisting even more on submitting earlier

[...]

>>   - There is also the angle that even if _Git_ doesn't benefit directly
>>     from people sticking around, those people may float into other open
>>     source projects and work on them. Which makes the world a better
>>     place on the whole.
>
> Yes, sure, OK. But if Git doesn't participate in GSoC this year
> another org will, and this same benefit will still be had by the
> greater open source community.

The greater open source community benefits a lot these days when Git
is improved and get new contributors, as git is now by far the most
widely used version control system in the open source community.
So my opinion is that we should have has many GSoC student as we can
properly handle.

Best regards,
Christian.

Re: Google Summer of Code 2013 (GSoC13)

[Matthieu Moy]

Christian Couder <christian.couder@gmail.com> writes:

> - yes, we could improve mentoring by providing better projects and
> insisting even more on submitting earlier

A few words about my experience, not with GSoC, but with school projects
(I've been proposing a few students in Ensimag to contribute to Git each
year since 2010).

Last year, we've been using Scrum, and the "definition of done" was a
very helpful tool. In Scrum, nothing is ever "half done", it is either
"done" or "not done". Out of a 3 weeks project, the definition of done
was initially "ready to be sent to the list", then "sent to the list, no
major criticism in reviews" the second week, and "sent to the list, no
more objections in reviews" the last week. At the beginning of each week
("sprint" in Scrum), students were commiting to a list of tasks, and at
the end of each week, we evaluated how many were done. This encouraged
students to avoid overcommiting and send patches early. Some of them
validated nothing at all the first week: they hadn't realized the
distance between their notion of clean working code and the one on this
list, but at least they realized it early enough.

Of course, even with that, I had to continue the work to push it to
master for some patch series, and discard some series that were
basically not there.

Having several small projects instead of one big was very important. I'm
not sure how the GSoC would feel about a list of small tasks instead of
one ambitious project however.

My main disappointment is that I never managed to keep students in the
community past the end of the project.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Google Summer of Code 2013 (GSoC13)

[Michael Schubert]

On 02/18/2013 06:42 PM, Jeff King wrote:
> 
> 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.
> 
> And I do not want to blame the students here (some of whom are on the cc
> list :) ). They are certainly under no obligation to stick around after
> GSoC ends, and I know they have many demands on their time. But I am
> also thinking about what Git wants to get out of GSoC (and to my mind,
> the most important thing is contributors).

Speaking of libgit2:

Git provided the libgit2 project with a slot each of the last three GSOC.
The contributions made by the former students (Disclaimer: one of them
speaking) have been quite important for libgit2 and all three students
are still involved. Each project was an important push towards building
a new, feature complete Git library.

Thank you!

http://libgit2.github.com

Re: Google Summer of Code 2013 (GSoC13)

[Carlos Martín Nieto]

Michael Schubert <schu@schu.io> writes:

> On 02/18/2013 06:42 PM, Jeff King wrote:
>> 
>> 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.
>> 
>> And I do not want to blame the students here (some of whom are on the cc
>> list :) ). They are certainly under no obligation to stick around after
>> GSoC ends, and I know they have many demands on their time. But I am
>> also thinking about what Git wants to get out of GSoC (and to my mind,
>> the most important thing is contributors).
>
> Speaking of libgit2:
>
> Git provided the libgit2 project with a slot each of the last three GSOC.
> The contributions made by the former students (Disclaimer: one of them
> speaking) have been quite important for libgit2 and all three students
> are still involved. Each project was an important push towards building
> a new, feature complete Git library.

Right, speaking of libgit2. GSoC has been very successful (as Michael,
I'm also somewhat biased) for libgit2. This happens outside of the git
ML so it probably hasn't gotten as much visibility here.

I believe it's partly because there were still larger parts where most
of the work was technical and the goal was quite clear, as git had
already set the standard and expectations and the decisions had to be
mostly about how to implement it in a way that makes sense for a
library, rather than it living inside of git, which is not always easy,
but you can experiment with different uses of it.

It's also possible that part of the success was the fact that we were
already acquainted with the "release often and early" policy, as we'd
been involved with FLOSS for a while already.

The current gaping hole in libgit2 is the lack of merge support, which
is the last hurdle to a stable 1.0 release. There is already some work
by Edward Thomson that needs to be reviewed and merged. I'm not sure
that there's enough for a whole summer there, but you could throw in the
review and merge of another missing feature, which is making the
reference storage generic, as it currently only supports the
git-compatible file-based one. There's other nice-to-have things like
thin-pack support that you could use to fill up a summer, though I'm not
sure that goes with the spirit of the programme.

Something else that needs love is Git for Windows. I believe both git
and libgit2 would benefit a lot from a project to take some parts of git
that are implemented in a scripting language and port them to use
libgit2. As Git for Windows needs to ship a ton of dependencies anyway,
using a pre-1.0 library wouldn't be an issue and it can be used to
experiment with an eventual porting of git to be one user of libgit2
rather than a completely different implementation. The more immediate
benefit for Git for Windows would be less reliance on languages that are
awkward to use on Windows and need their own environment. Mentoring from
the libgit2 probably wouldn't be much of an issue to organise, though
I'm not sure if the GfW team would have time for the part that involves
its peculiarities.

So there's a couple of projects that could be done with some realistic
chance of being merged upstream, as they'd be technical, as long as we
do tell the student to send small units of work to be reviewed often.

Cheers,
   cmn

Re: Google Summer of Code 2013 (GSoC13)

[Thomas Rast]

Shawn Pearce <spearce@spearce.org> writes:

> On Mon, Feb 18, 2013 at 9:42 AM, Jeff King <peff@peff.net> wrote:
>> On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:
>>
>>> * We need an org admin.  AFAIK this was done by Peff and Shawn in
>>>   tandem last year.  Would you do it again?
>>
>> 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.
>
> This.
>
> I actually think Git should take a year off from GSoC and not
> participate. Consequently I will not be volunteering as backup org
> admin.

Fair enough.  But I think if that's the decision (and modulo libgit2
praise, it seems to be pretty much the consensus?), we should probably
have some Idea why we are doing it?

You wrote:

> Git has been involved since 2007. In all of that time we have had very
> few student projects merge successfully into their upstream project
> (e.g. git.git, JGit or libgit2) before the end of GSoC. Even fewer
> students have stuck around and remained active contributors. When I
> look at the amount of effort we contributors put into GSoC, I think we
> are misusing our limited time and resources. The intention of the GSoC
> program is to grow new open source developers, and increase our
> community of contributors. Somehow I think Git is falling well short
> of its potential here. This is especially true if you compare Git's
> GSoC program to some other equally long-running GSoC programs.

If that's the outset (and it's certainly true for a lot of the
projects), aren't the options (not limited to just one):

* We have some discussion about why we fail, what to do better, etc. and
  hopefully also manage to clean up some old projects and get them
  included.  That way we can learn something from it.

* We try to look at how more successful communities are doing it
  (e.g. there were some posts about how KDE bumped their student
  retention rate).

* We try to "mentor" some projects that aren't GSoC sponsered.  That way
  we can hope to gain mentoring experience.

I'm not very optimistic about any of these, as:

- There weren't any in-depth discussions post-GSoC to analyze what went
  wrong.

- Contributor time is so limited that we're usually short on reviews.
  Adding "mentoring for the sake of trying it" to duties isn't very
  promising.

Thus I'm a bit afraid that after a year off, we won't have learned
anything new.  To the contrary, some previous mentors/students will
inevitably have disappeared into the mists of time, and with them their
experience.  Unless we do something about it, next year we'll be in an
_even worse_ position than this year.

I'm mildly pessimistic about "doing something" over the list, but
perhaps we can have an extended discussion at git-merge provided enough
of you show up there?  I can try to prepare some material.


(Maybe we should all make a bunch of clones of ourselves.  We can put
one copy each into a room so they can figure out GSoC, and have another
group doing our favorite git hacking while we're at it.)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Google Summer of Code 2013 (GSoC13)

[Florian Achleitner]

[corrected David Barr's address]
On Monday 18 February 2013 12:42:39 Jeff King wrote:
> And I do not want to blame the students here (some of whom are on the cc
> list  ). They are certainly under no obligation to stick around after
> GSoC ends, and I know they have many demands on their time. But I am
> also thinking about what Git wants to get out of GSoC (and to my mind,
> the most important thing is contributors).

Just a little comment from another student:
Last year i worked on the 'remote helper for svn'. My official mentor was David 
Barr, but I had most interaction with Jonathan Nieder.

>From my point of view I wouldn't say the project was a fail. It was harder 
than I originally thought, yes. That happens.
But we have a remote helper in master now, although its far from complete and 
it's development is quite stalled. (remote-testsvn)

About sticking around:
As you can see I read the list (I was not on CC), but not very regularly, I 
admit. Anyways, I'd respond to mails in CC or on IRC.

During the summer I believe I learned git's development process quite well. I 
rerolled my main patch series 8 times until 19th of September, which is well 
beyond GSOC deadline. I tried to get it finished before concentrating on my 
studies again.

If I would now continue to contribute, it would be a completely new topic 
(like branch mapping) and take a lot of time that I don't have during the 
year, where I have to push my studies forward. 
For a student one aspect of  GSOC is also quite important: It is a cool and 
demanding summer job during the holidays, but it has to ramp down when the new 
semester starts.

Anyways I think GSOC is a great idea and I enjoyed contributing to git  a lot, 
would immediatly do it again. Keep it goin'!
Thanks.

Florian

Re: Google Summer of Code 2013 (GSoC13)

[Junio C Hamano]

Florian Achleitner <florian.achleitner2.6.31@gmail.com> writes:

> For a student one aspect of  GSOC is also quite important: It is a cool and 
> demanding summer job during the holidays, but it has to ramp down when the new 
> semester starts.

Thanks for sharing.

I think an important lesson is that mentors and reviewers need to
think really hard to limit the initial scope of the assignment to be
not too ambitious.  Starting with an ambitious goal and achieving
only small first steps of them _can_ still be a good end result, but
if a mentor wants to go that route, the decision to cut down the
scope of an ambitous assignment needs to be made early enough to
leave sufficient time to wrap up the half-done assignment in a good
shape. Finishing with implementation of only the initial 30% of an
unproven design, that by itself is not useful, does not help our
project at all, and it does not give satisfaction to the student,
either.

Re: Google Summer of Code 2013 (GSoC13)

[Jaseem Abid]

On Mon, Feb 18, 2013 at 10:53 PM, Thomas Rast <trast@inf.ethz.ch> wrote:

> * We should prepare an "ideas page".  Last year, Peff made one on
>     https://github.com/peff/git/wiki/SoC-2012-Ideas

[Resending the mail, because the last one failed because of inline html content]

One of the proposed ideas last year - 'Use JavaScript library /
framework in gitweb'

I wanted to work on this project last year, but Git community didn't
get a slot for the project from Google. I still worked on it and
almost finished it. Sadly I never got time to polish it to merge to
master. you can see some of my commits on it here.
https://github.com/jaseemabid/git/commits/gitweb

Detailed notes on what actually did.
https://gist.github.com/jaseemabid/3218461


Gitweb is 1 huge perl script and even though it *works*, it is a poor
work in 2013. The code is pretty old and is a hard thing to jump into.
Quite a few here helped me to get started and it was a pretty good
experience. Jakub was the mentor. Ram and John 'warthog' Hawley
occasionally helped with git and general feedback back then. Andrew
Sayers <andrew-git@pileofstuff.org> helped a lot, but he just
disappeared one day.  I remember John mentioning about splitting the
file into smaller ones, rewriting some sections, adding more
documentation etc. I'm not sure if any work was done on this. I
couldn't follow the project for sometime.

I will try to make some time and finish it off in the next week or so.
I am having a bad schedule now between school and job, but will try my
level best.

--
Regards,

Jaseem Abid
github.com/jaseemabid