git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: "Integrated Web Client for git" GSoC proposal

From
Jakub Narebski <jnareb@gmail.com>
Date
Apr 16, 2010, 13:03 UTC
Message-ID
<201004161503.34991.jnareb@gmail.com>
In-Reply-To
<7vvdbuqh2c.fsf@alter.siamese.dyndns.org>
Dnia środa 14. kwietnia 2010 15:50, Junio C Hamano napisał:
Show 25 quoted lines
> Petr Baudis <pasky@ucw.cz> writes:
> 
> > Well, it's not that noone maintains gitweb or noone reviews patches;
> > smaller changes do get merged relatively fine (I'd hope), but larger
> > changes get sidetracked in endless discussions and perpetual polishing.
> >
> > I think the problem is that we are extremely perfectionistic about
> > whatever gets into gitweb ...
> 
> Hmph, from time to time, I found review comments that were too picky, but
> I don't think gitweb reviews are particularly "perfectionistic".
> 
> What I find is more problematic is the lack of post-review follow up,
> especially when the submitter disappears without responding to the
> reviews.  To patches that are in the core-git area, I find myself doing
> the "finishing touches" in such a case if/when the topic deserves it.
> What gitweb needs may a dedicated shepherd or two.
> 
> > ... but other than that I think gitweb just
> > needs more of the "best is the enemy of good" mentality.
> 
> If that means I'd see more "These are a resend of the good enough version
> of patches with our Acks; apply them" from you and/or Jakub, or "In this
> repository, we have queued the good ones---pull them", which is even
> better, I am all for it ;-).
Well, I try to either save interesting gitweb patches (which doesn't help
much), or import them to my repository at
  http://repo.or.cz/w/git/jnareb-git.git

The interesting branches would be gitwe/* branches. Some of them are regularly rebased against 'master' branch of main git repository.

Those branches are:
gitweb/web::
  The branch that I am doing miscelanous gitweb development on.  Managed
  using StGit, not all patches applied (visible).  Regularly rebased 
  against 'origin' branch.
  Currently contains syntax highlighting support from Johannes Schindelin
  (based in turn on Daniel Svensson's and Sham Chukoury's work in
  gitweb-xmms2.git), plus my refactoring of that.
  Needs decision on names of subroutines, and on semantics of 'highlight'
  feature (on/off, or highlighter name).
gitweb/cache-kernel-pu::
  Simple file-based output caching for gitweb, based on work by John 
  'Warthog9' Hawley (J.H.), split into smaller patches for easier review.
  Much more configurable than original patch(es) by J.H., with pluggable
  caching engine (it works for example with Cache::FileCache).
  J.H. ideas were: no serialization and mtime based expiration of simple
  file-based cache, using locking to avoid 'cache miss stampede' problem,
  serving stale data when cache entry is being regenerated, generating
  cache in background, trick for non-AJAXy progress info, having everything
  related to cache in 'cache.pm' file.
  My ideas were: tests, separating simple file-based cache into separate
  package and making it easy to replace this cache engine by any
  Cache::Cache or CHI cache driver, select(FILEHANLE) based capturing,
  separating capturing output into package to be able to replace it by
  other captyring mechanism, daemonizing for background cache generation
  (for mod_perl), being able to 'require' the 'cache.pm' file, gathering
  options in %cache_options and adding configurability, documentation.
  This is work in progress, and a bit of mess currently.  I have posted
  information about current state of this branch to git mailing list.
  Rebased on top of 'origin'.

gitweb/cache-kernel-v3:: gitweb/cache-kernel-v2:: gitweb/cache-kernel::

  Gitweb caching series, as send to git mailing list.  Not modified, here
  for historical reasons.
gitweb/category::
  The "nitpicked to death" series by Sebastien Cevey.
  I have meant to fix the way list of projects is displayed first, to
  separate filtering list of projects and printing list of projects,
  but never did managed to get to it.
  Rebased on top of 'origin'.  Series is stalled.
gitweb/committags::
  Series by Marcel M. Cary.
  I have meant to comment on this series, but forgot about it.  The major
  problem is deciding how to configure this feature... and how to name it.
  It is decision about API (configuration), so it is important to get it
  right the first time.
  Needs review.  Series is stalled.
gitweb/cache::
  Old caching (pre-GSoC2009 gitweb caching project even) of Perl data,
  for projects_list page only, by Petr Baudis.  Some version of it might
  be used on http://repo.or.cz
  Abandoned for now.  Needs checking which method of caching is better.
-- 
Jakub Narebski
Poland
Previous: Jakub NarebskiNext: Pavan Kumar Sunkara
Message 6 of 8 in “Re: [spf:guess,iffy] Re: "Integrated Web Client for git" GSoC proposal”
  1. Jakub NarebskiApr 16, 2010
  2. Sam VilainApr 17, 2010
  3. Tatsuhiko MiyagawaApr 17, 2010
  4. Jakub NarebskiApr 17, 2010
  5. Jakub NarebskiApr 17, 2010
  6. Jakub NarebskiApr 16, 2010
  7. Fwd: Re: "Integrated Web Client for git" GSoC proposalPavan Kumar Sunkara, Apr 17, 2010
  8. Jakub NarebskiApr 17, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.