Git Migration Needs YOU!

[Lukas Appelhans]

Am Montag 01 März 2010 21:54:34 schrieb 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.
Hey!

We are working on it™ (or at least Joris is I hope)...

The plan is to split out libbtcore completely from ktorrent, so we can use it 
as a normal dep or a simple copy of the stable branch...

Lukas
> 
> > -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?