Braindump for Evaluate move of LCFG configuration from svn to git

What needs doing.

The basic questions to answer are these:

Would it be possible to manage the headers & package lists using git rather than subversion?

Can we still have a weekly testing/stable release cycle, and do it just as easily as at present?

However there's a lot more than that to look at and think about - for example code review; the sharing of config and responsibility between multiple schools and units; who should have access to commit changes to what; who should control that access; how to encourage contributions. This could take us deeply into the zone of people and politics rather than just technical detail.

Nascent project plan

Without a proper plan the project has floundered somewhat. Here's an expanded proto-plan:

  • Make separate git repositories out of the current 'dice' and 'lcfg' bits of the current lcfg configuration subversion repository. (1 day)
  • Make a play lcfg slave and get it to use the git repositories for its config. (1 day)
  • Look for multiple gitty ways in which the releases might be done. (several days?)
  • Come up with several ways in which the repos could be organised, see if they suit git better than the current subversion repo structure. (several days?)
  • Add gerrit in front of the lcfg git repository. (1-2 days?)
  • Ask others to play with lcfg/git/gerrit. Get their opinions (positive or negative, verbal or written, short or long) (a day or two of effort over a longer elapsed time?)
  • Write it up. Present options and possibilities (days)

General git resources

Setting up the test bed.

Subversion to Git - some reading:

Splitting the repository:

Firstly we want to preserve our years of commit history so we start off by cloning with 'git svn clone'. There are various details to take care of here such as converting usernames to the proper "name and email address" git format, and preserving tags, and so on. But basically it's "git svn clone" with bells on.

Secondly you can (says 'git svn clone' just a subdirectory of a subversion repository. Try this.

Or the split could be done at the subversion stage using 'svnadmin dump', 'svndumpfilter' and 'svnadmin load' as described in the svn book

Driving an LCFG slave from the git repo(s):

git hooks


There seem to be various ways in which branching and tagging could work for releases. Come up with some possibilities and try them out.

Access permissions and Gerrit

What are the current access permissions to svn? And what would we like them to be? How could either of these be reproduced for git?

And what about gerrit - who should be allowed to make contributions? What has to happen to get a commit approved? Who needs to be involved? Who could be involved?

How should gerrit be set up to get the best balance between on the one hand safely accepting config from a wider group of people, and getting more eyes on config changes, and on the other hand not getting in peoples' way (so that they just go and put their config elsewhere instead)? We must bear in mind that contributing config code to the lcfg layer will not be the main objective for most people, but a side effect: the main aim will be to configure machines, and this can be done at a number of levels, not all of which will be controlled by gatekeepers.

Related questions

Could we come up with a totally automated machine installation - or other meaningful/useful tests - enabling us to move towards a 'continuous integration' setup, and away from weekly releases?

Could we drive multiple units/schools' LCFG services from the same repository in a parallel way, rather than the current upstream/downstream way? This could move us closer to having machines in more parts of the university being directly dependent on the current proper functioning of the develop release.

Topic revision: r1 - 20 Dec 2013 - 15:44:31 - ChrisCooke
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies