Git Migration Needs YOU!

[Aaron J. Seigo]

On March 1, 2010, Chani wrote:
> -we have six blockers listed on the techbase page[1]. One is between the
> board and Shortcut (the company behind gitorious.org), two will require
> co-operation from Shortcut after our part is done, and the remaining three
> are entirely KDE's responsibility.

2.3 Script for downloading virtual KDE hierarchies: doesn't look like a 
blocker (and even looks like it duplicates some effort with kdesvn-build)

2.4 Push log: a nice to have, but not a blocker afaics

2.5 pre-receive hooks: if we self host, easy to solve. if we go with 
gitorious.org, is it really a blocker?

2.6 Get rid of svn:externals: i'd like to ask that these not be considered 
blockers and are instead removed in svn immediately even at the cost of 
features if need be. there are only two in blocker positions and i'll try to 
get to the one in kdebase today. kget should simply have the svn external 
removed and that code disabled until they figure it out.

> -one of the blocker tasks is, uh, rather large. humongous, in fact. we
> could really, *really* use more volunteers for the svn2git rules.

yes, this is the key issue, isn't it?

here's the problem though: it is documented sufficiently.

there are wiki pages on gitorious.org that are not linked to anywhere, there 
is next to no information about how long it will take, what i should be 
looking for to know i've ahieved success (and what "success" is). essentially, 
i have no way of knowing how to get started, how to target a specific module 
or how to know i've done something useful.

this must be fixed ASAFP. can someone who has done one of the other modules 
please document the process completely and thoroughly on techbase (NOT 
gitorious.org!) so that others can help out?

> -the svn2git progress chart is also a map of what git repos will be
> created. how to split things up has been debated many times and the exact
> same conclusion was always reached, so let's not start that again.

right, that particular conversation is _over_ and there is no point in going 
over it again. the result MUST be documented on techbase and further 
bikeshedding simply shutdown.

> (exception: there's a few things at the bottom, folders I don't think
> anyone realised were in svn at all, so I don't have any record of what to
> do with them)

must move:
	kde-common
	quality
	tests 

let it die unless someone steps up unexpectedly:
	kdenox
	kdesecurity
	konstruct 

playground should be left up to the people working on things in there. 
kdereview needs to be addressed ASAP since it's part of our workflow.

git gurus: how can we best approximate such a staging area with git?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks