migrating KDE's main modules to git

[Aaron J. Seigo]

hi everyone ..

first, apologies for the massive cross posting, but we have 4 different groups 
that all need to provide some critical input so that we can move KDE's main 
modules into git as planned. movement is needed and i'm being my usual 
presumptuous self and writing an email in hopes of getting these things 
accomplished with the help of all of you.

since each of our input needs to be coordinated with or affects the input 
and/or results of others, i'm doing this in one big email. if you reply, 
please only keep the relevant groups (which is either just k-c-d or k-c-d + 
relevant mailing list) in your replies. if you wish to reply to differents of 
the email, consider making them in separate emails with the appropriate CC's. 
not particularly beautiful, but i can't think of another approach that reaches 
everyone necessary while limiting cross-talk.



Dear KDE,

We need to write rules for the modules involved in the SC. Progress on the 
modules as of quite a few months ago now can been seen in a table here:

http://techbase.kde.org/Projects/MovetoGit#Write_.2F_update_importing_rules_for_svn2git

Not great, right? :) Well, we need to fix that. Better yet: we can! How to 
write the rules is documented here:

	http://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git

My proposal to finally achieve success on this is simple:

	Starting 6 weeks prior to git opening up to KDE's main modules, 
	host a meet up on IRC once a week to work on the rules. 

The more people we can get to attend and work on the rules in those weeks 
leading up to git.kde.org being opened to SC modules, the better.

As with all simple plans, though, there may well be a better, albeit more 
involved, one. If you have one, please reply to kde-core-devel (remove the 
rest of the CCs!) with your ideas. If you'd like to be involved, also feel 
free to say so. If you'd like to help in leading this, also please say so!

Thanks! :)



Dear Sys Admin,

according to the git migration schedule here:

	http://community.kde.org/Sysadmin/GitInfrastructureLaunch

new KDE projects will start moving into git.kde.org on September 29th. it is 
noted that KDE modules aren't welcome until November 17th and we are also 
likely to experience a scheduling delay as noted here:

	http://www.omat.nl/2010/08/13/git-infrastructure-delayed/

To facilitate all aspects moving forward effectively, it would be great if 
sysadmin could clarify two points:

* Is the November 17th date a hard date requirement, or can we start moving 
main modules into git.kde.org earlier if we are ready to do so? Why / why not?

* The projected delay is due to waiting on password->ssh account conversions; 
can we get guidance on the nature of the delay? (e.g. latest date willing to 
wait, or if sys admin is not willing to make that call and therefore KDE needs 
to provide such a definition for sys admin to simply implement.)

Finally, we used to have a "TODO" tracker on the wiki here:

	http://techbase.kde.org/Projects/MovetoGit

Obviously, this is pretty much out of date with regards to the current state 
of things. Can someone with the knowledge of what's happening update the times 
of ites that the sys admin plans have taken care of?

Thanks! :)



Dear SCM Interest,

there has been endless discussions over time about how best to turn the 
existing SC modules into git repositories. they keep happening over and over 
with those who do not agree just bringing up the topic all over again, 
destroying whatever consensus may have been reached previously. this causes 
frustration and fatigue. as a result, it is rather irresponsible behaviour. 
i'd like to therefore ask those involved to stop that cycle and turn it into 
something the rest of us can use.

let's be clear on this: no matter what solution is decided on, we will make it 
work. there also probably isn't a "vastly superior to every other answer" 
solution, but only solutions with different strengths and different 
challenges.

the people on the scm interest are the best equipped to come up with these 
answers, as you have the knowledge. please come up with a recommendation (or a 
limited set of competing recommendations for KDE to chose from, if that's not 
possible) in written form. include the workflow, benefits and challenges. 
include what new efforts, if any, are needed to achieve the recommendation.

Please keep KDE's SC goals in mind when coming to conclusions, such as:

* our downstreams are critical to us and the SC affects them immensely; we 
need to think about them as much as we think about ourselves in this

* we are used to working in certain ways, and they generally work very well. 
they may well be improvable, but they aren't particularly broken either. the 
cost of change needs to be weighed against the benefits of improvement in any 
recommendation.

* the vaue of the SC is that it is a compilation of recommendations.

Can you please provide k-c-d with a firm time commitment as to when this 
document will be delivered so that we can track its progress along with all 
the other bits that are flying about? It's not so important if it takes one 
week or three weeks, we just need (and deserve!) to know when to expect this 
guidance so we can start crafting migration rules that follow this.

Thanks! :)



Dear Release Team,

You have final say on all matters release-y around the SC. When we migrate SC 
modules into git, it needs to be timed with a given release. Can you please 
provide us with guidance as to what this should look like? It doesn't need to 
be matched to a specific release schedule (e.g. 4.6 or 4.7) but just a set of 
requirements/recommendations for how it should align to a generic six month 
cycle.

Thanks! :)



And finally: thank you to everyone who will be helping to make all of the 
above come true with success. It's going to be humongous.

Hugs to everyone who has already put some of the time, energy and mirth into 
this.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20100823/e6394f51/attachment.sig