gEDA is moving to using git

A few days ago in response to other developer's comments/complaints on moving gEDA to using Guile 1.8, I suggested forking a stable branch of gEDA which would use Guile 1.6 while keeping the main development tree using Guile 1.8.

Ales decided this was a good idea, saying:

Here's the plan going forward:

• I do want a stable/unstable branch/release arrangement going forward.
• I do not want to use CVS to maintain this though.
• So, I am going to go ahead and setup a git repository as the official repository of gEDA/gaf.

I think this is really good news, as git is so much better than CVS in many ways, most importantly (in my opinion) the speed and ease of branching, merging and maintaining patch sets. The web interface is better too.

One unresolved problem, though, is that Ales has not yet decided what to do about committing to the new unstable git branch (he's decided to maintain the stable branch himself, accepting patches by e-mail & SF tracker). There are a number of options.

The first option is the Linux kernel model: each person has their own repository, and the repository belonging to the head honcho (in gEDA's case Ales) is the "officia" repository. In this case, the approach would be as follows:

1. A select (probably less than five) group of people (let's call them maintainers) have their own repos on git.gpleda.org (or elsewhere), from which Ales "pulls" changes. These would likely be people Ales trusts not to break anything or commit anything he wouldn't like to see in the master tree quite yet. Each maintainer would probably have a "for-ales" branch, to make sure that only changes that are ready go upstream.
2. Developers who are not maintainers and don't mind using git could use git-mail (and associated tools, such as StGit's mailing tool) to send patches by e-mail to a maintainer, who would integrate them into their personal repository. This is good for people who only make changes infrequently, or new developers "on probation". Git provides very good tools for importing changes from mbox files, so it's not too much work for the maintainers.
3. Those developers who don't like git could use git-cvsserver to browse the history and generate patches (which are again sent to maintainers).

The second option is a "shared central repository", as used by the X.org project. This is very similar in workflow to CVS, where there is a single central repository.

1. Some people would have the ability to "push" to the central repository. They could do this either using git or the git-cvsserver. People could have their own branches in the central repository, probably named "userid-topic".
2. Other developers would need to send their patches by e-mail or using the SF.net trackers.

Because the rate at which gEDA is developed is currently quite slow, I think the second option would be best for now, as it would make for a smoother transition from CVS to git. Since it is easy to switch from one approach to the other (and back again, if need be), it will be possible to experiment with other options if problems crop up.