atom feed14 messages in org.kde.kde-scm-interest[Kde-scm-interest] Minutes from Today...
FromSent OnAttachments
Ian MonroeJul 8, 2009 9:43 am 
Albert Astals CidJul 8, 2009 9:51 am 
ChaniJul 8, 2009 10:03 am 
Andrius ŠtikonasJul 8, 2009 2:21 pm 
Michael PyneJul 8, 2009 4:11 pm 
Jeff MitchellJul 8, 2009 5:13 pm 
Ian MonroeJul 8, 2009 6:05 pm 
Ian MonroeJul 8, 2009 6:08 pm 
Leo FranchiJul 9, 2009 1:17 am 
Leo FranchiJul 9, 2009 1:17 am 
Andrius ŠtikonasJul 13, 2009 9:29 am 
Simon HausmannJul 17, 2009 1:01 am 
Johannes SixtJul 17, 2009 1:19 am 
Thomas ZanderJul 17, 2009 1:27 am 
Subject:[Kde-scm-interest] Minutes from Today's KDE -> Git BoF
From:Ian Monroe (ia@monroe.nu)
Date:Jul 8, 2009 9:43:19 am
List:org.kde.kde-scm-interest

This is the minutes Leo wrote while the meeting was going on, so its a bit stream-of-consciousness.

Notes from KDE + Git BOF:

Current situation: amarok goes first, gets basic infrastructure set up, scripty, etc.

what do we need for the git transition?

pre-commit hooks (acltest, docbook, EOL/UTF-8) post-commit hooks (BUG/CCMAIL, email/CIA, license header checks) techbase documentation convert all accounts to SSH 1 project for all accounts on gitorious? sub-project membership? how should gitorious account system work get rid of svn:externals how do the people get accounts on gitorious? telling them to make one themselves puts up a big hurdle that people don't need reviewing of patches snapshot to read-only svn? (it's work, but maybe some people would like it)

--> NEEDED for documentation, in order to get it back into SVN for the translators/scripty/?

check with other platform guys

convert!

thiago's proposal for splitting: split the main modules at the module level (kdemultimedia, kdebase). Extragear & playground will be split at the application level---e.g. amarok/k3b/whatever. at last count, that leaves us with ~450 repos. will it raise the bar to create new apps if we do this application-level split? is that a good side effect? probably---many apps with just 1 or 2 commits.

android repo tool: good for downloading/updating multiple git repos and could create a tree of git repos, but "repo" has 2 features: also pushes changesets to a server-side reviewboard, which we don't really want (and gitorious doesn't support yet). could split repo out (thiago talked to shawn pearce), or something else.

how do you support relocating code within KDE?

importing in to one of the main modules is not hard taking something from main->non-main module is done little. (but is possible, if complicated)

gitorious is expensive: we have a lot of anonsvn bandwidth for free. we could use gitorious for our git server, and mirror anon-git on our free high-bandwidth anonsvn servers.

how do we get over the initial hump---everyone needs to clone at the start, so we'll need a lot of bandwidth to get it all out.

let's postpone (perhaps forever) the www.kde.org switch to git, not as necessary, small number of people who access it with complex ACL.

KDE accounts file is no longer useful---used for mapping svn ID -> email, but we have that now from gitorious.

what is the "canonical", "official" repo of KDE? talking with the marketing team, the canonical place to get KDE should be on a kde.org domain. e.g. git.kde.org. Gitorious folks said they could do this, its trivial.

FUNDING - FUNDING - FUNDING! (some people inside Nokia have indicated support, also KDE e.V. board has some infrastructure budget).

JOBS:

sebas: talk to people using other distros about git danimo: talk to windows guys machael jansen: talking to kdesvn-build/mpyne thiago and sebas: funding jonas: domain name simon: snapshot to svn (for docs) darktears: reviewboard/patches thiago: actually convert :D dfaure: get rid of svn:externals ML: convert to SSH lots of ppl: write docs on techbase! chani: techbase docs for scripty thiago: pre/post-commit hooks sebas/lydia/leo: communication with teams! tell people! keeping track that everything is being done.

TIMELINE:

amarok first, then also phonon... then talk about whether to go all together or piecemeal. thiago prefers all at once. --> ideally before 4.4 freezes, but it has to be after 4.3 is branched.

must proactively go out and spread the word on how to do the migration -- COMMUNICATION