Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?

From: Jakub Narebski <jnareb@gmail.com>
Date: Aug 15, 2008, 20:36 UTC
Message-ID: <200808152236.56479.jnareb@gmail.com>
In-Reply-To: <48A5DB4D.5060906@gmail.com>

On Fri, 15 August 2008, Lea Wiemann wrote:

Show 15 quoted lines

> Jakub Narebski wrote:
> > 3. Gitweb caching
> > 
> > Student: Lea Wiemann
> > Mentor: John 'warthog' Hawley
> > 
> > There are new tests for gitweb (to check if caching would not break 
> > anything new: it did caught a few breakages), new object Perl API to 
> > git, and gitweb caching implemented using caching data at the level 
> > slightly above calling git commands.  But full code (tests, Perl API 
> > and changes to gitweb) are only after first, maybe second round of 
> > review.
> 
> Correct.  I'm planning to post the next round of patches tonight or
> tomorrow. [...]

Please remember that according to timeline in GSoC 2008 FAQ:
  http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
August 18: ~12 noon PDT / 19:00 UTC is "Firm 'pencils down' date."
(suggested pencils down date was August 11).  So you don't have much
time, and you don't leave much time for review, so I guess evaluation
would be "done, but nor merged in" or something like that.

> 2. I'll run benchmarks under various conditions, to measure how much
> performance we gain with caching, and under what conditions it is most
> beneficial.

And to compare with plain, vanilla gitweb, with kernel.org fork (both performance and disk space used I guess) and repo.or.cz fork (only caches projects list view, IIRC), I guess.

Benchmarking gitweb caching could be difficult, as you would have somehow (fio?) replay conditions of I/O pressure as on kernel.org and repo.or.cz, as from anegdotical evidence gitweb is IO bound, not CPU bound (so ordinary speed benchmarks could give wrong results).

Show 7 quoted lines

> > Student retention: unknown.
> 
> Well, on the downside, I'm expecting to be pretty busy with college, so
> there won't be much time to do substantial work on git or gitweb.  On
> the upside, I feel perfectly comfortable with contributing to git (i.e.,
> maintaining my own patch queue, sending patches, etc.), so it's very
> much possible that at some point I'll be hacking git or gitweb again.

It would be nice, even if you would be a "weekend contributor".

But I guess that making you into gitweb maintainer, or git.kernel.org admin is out of the question... ;-)

-- 
Jakub Narebski
Poland