GitTogether topics status (4th of October)

Hi,

As can be seen on the GitTogether page on the wiki: 

http://git.or.cz/gitwiki/GitTogether

the planned speakers/topics changed a lot during the last weeks and are now:

- Johannes Schindelin (Google Tech Talk, 1 hour):
	Contributing with Git (or: all your rebase are belong to us)

- Shawn O. Pearce (Talk + Brainstorm, 1 hour):
	Introduce the secret bundle project

- Shawn O. Pearce (Talk + Debate, 0.5 hour):
	JGit, where is it going?

- Shawn O. Pearce (Talk + Plan Hacking, 1 hour):
	Pack v4, what's stopping you?

- Sam Vilain (?):
	GitTorrent, Git as a DB backend, perl.git conversion

- Junio C Hamano (Talk, 1 hour):
	Git Chronicle, Recent Additions to Git

- Scott Chacon (Talk/Discussion, 1 hour):
	Linkable library, Scriptability

- Scott Chacon (Hack Session(proposed)):
	Architecting / Building a usable linkable library

- Scott Chacon (Lightning Talk, 10 min):
	iGitHub - git daemon and repository browser on the iPhone

- Tom Preston-Werner (Talk/Discussion, 1 hour)
	Git ideas from GitHub

- ? (Talk/Discussion, 1 hour):
	New git homepage hammering out

- ? (Talk/Discussion, 1 hour):
	Git GUI that even a designer would use

There are still many things that are not clear or undecided. So more input is welcome.

The topics suggested on the wiki are:

 * GitTorrent: current state, security considerations, future direction
 * Submodules: how to make a UI for this important feature that is intuitive 
and complete
 * PackV4
 * JGit, quo vadis?
 * Using Git for everything but source (Git as a backup tool, how to handle 
large blobs, using as a DB back-end, etc)
 * How to make Git more attractive to the Google Code folks?
 * Success/War stories (big wanking session for Gits)
 * perl.git - the joy of grokking Perforce metadata using Postgres, and 
writing a transactional git-fastimport exporter SamV
 * Linkable library for basic object access (libification or new library)
 * Scriptability, using git in other languages (using interfaces vs calling 
plumbing vs reimplementting) 
 * Git GUI that even a designer could use (GitCheetah, AKA TortoiseGit?) (UI 
session?)
 * Git integration with IDE, RAD, and editors (UI session?)
 * New Git Homepage hammering-out (UI session?)
 * Shawn's current bundle related secret project
 * TopGit introduction/design/integration(?)
 * Pasky's current pickaxe related "secret project" (if tangible by then)
 * Extending Git with volatile metadata database (see 
[http://mid.gmane.org/20080910164045.GL10360@machine.or.cz 
20080910164045.GL10360@machine.or.cz])
 * Git improvement ideas gleaned from creating and running Git``Hub as a 
social layer on top of Git
 * Git Survey 2008 results and discussion
 * Free form "We tried to use git in our project this way, didn't work very 
well" session, where participants are not allowed to say "Your workflow is 
broken".

Thanks, Christian.

On Sat, Oct 04, 2008 at 06:16:40PM +0200, Christian Couder wrote:

I just added two proposed half-hour meetings, both of which I intend to be a few minutes of me talking followed by group discussion. The topics are:

  1. Helping new developers join the git community

     This title is a little bit sneaky. I want to talk about not just how
     we can get new developers to help improve git, but also how we can
     convince them to adopt workflows that make less work for reviewers
     and maintainers. It seems like there are some things that we tell
     new people over and over about formatting code, formatting patches,
     sending patches, etc. Probably the end goal will be improvements to
     SubmittingPatches, but maybe putting similar content somewhere more
     visible, or maybe even adjusting our workflows a bit.

     I hope to make it useful for veterans (who may _constructively_
     complain about the habits of new developers), and new developers,
     who may learn something about contributing.

     This might overlap a bit with Dscho's "contributing with git" talk
     (which I am not sure is a talk about using git to contribute in
     general, or using git to contribute to git), but I think the
     discussion-like forum will make it different enough to be valuable.

  2. What needs refactoring?

     I occasionally run up against parts of the code that just make my
     eyes bleed everytime I touch them. I think we've made significant
     progress in maintanability and bug-avoidance with things like the
     strbuf library, refactoring of remote and transport handling, etc.
     What areas might still benefit from such refactoring?

-Peff

On Mon, 6 Oct 2008, Jeff King wrote:

Tree object walking and commit object parsing. This is what's holding pack v4 performances back. But I think that Shawn will cover this already (I won't be there but I sent my thoughts about this to him).

Nicolas

Nicolas Pitre <nico@cam.org> wrote:

Yup. A huge part of the pack v4 talk is going to be the parsing code. Maybe 10 minutes of it will give the high level overview of how pack v4 is organized, to explain why the parsing code is a problem. :)

Jeff King <peff@peff.net> wrote:

Oh, this is a good idea.  Yesterday I myself had trouble with
a new contributor not being familiar with the patching process.
Partly also my fault of still being a green maintainer.  ;-)
 

Also a good idea. I imagine Junio may have some interest in this. I certainly do. Some of the code is just bloodly aweful to work with. I guess those are the parts that make your eyes bleed.

Christian Couder schrieb:

While I won't be there, another good topic might be the usage of a patch tracker like patchwork (http://ozlabs.org/~jk/projects/patchwork/).

René