Difference between revisions of "Projects/MovetoGit"

Jump to: navigation, search
(Update Krecipes status)
(Fix links to build-tool and kdesrc-build.)
 
(35 intermediate revisions by 15 users not shown)
Line 4: Line 4:
  
 
Meetings are wednesdays, 19:30 UTC, in #kde-git.
 
Meetings are wednesdays, 19:30 UTC, in #kde-git.
 +
 +
'''New! [http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting The best way you can help us migrate]'''
  
 
=The Plan=
 
=The Plan=
  
KDE is, eventually, moving to Git. We will be using gitosis + Redmine + reviewboard on our own servers.
+
KDE is moving to [https://projects.kde.org/projects Git]. We will be using gitolite + Redmine + reviewboard on our own servers.
  
 
In the summer of 2009, [http://gitorious.org/amarok Amarok] moved to Gitorious to test the waters and find problems that would affect KDE.
 
In the summer of 2009, [http://gitorious.org/amarok Amarok] moved to Gitorious to test the waters and find problems that would affect KDE.
Line 14: Line 16:
  
 
Once those problems have been solved, all of KDE will be able to switch.
 
Once those problems have been solved, all of KDE will be able to switch.
 +
 +
A full schedule for the git infrastructure can be found [http://community.kde.org/Sysadmin/GitInfrastructureLaunch here].
  
 
==Why?==
 
==Why?==
Line 22: Line 26:
  
 
When we move, KDE's svn repository will be migrated into several Git repos, all on git.kde.org. Main modules such as kdelibs and kdebase will each become one repository. Projects in extragear will each have their own repository. The projects.kde.org site will have a list (lists?) of all these repositories using the redmine project wiki. Scripts will be provided for downloading, say, all of extragear, so "moving" a project from kdereview to extragear would simply involve editing a file kept online that defined the location of projects.
 
When we move, KDE's svn repository will be migrated into several Git repos, all on git.kde.org. Main modules such as kdelibs and kdebase will each become one repository. Projects in extragear will each have their own repository. The projects.kde.org site will have a list (lists?) of all these repositories using the redmine project wiki. Scripts will be provided for downloading, say, all of extragear, so "moving" a project from kdereview to extragear would simply involve editing a file kept online that defined the location of projects.
 +
Details on the reasoning behind this layout is available [[Projects/MoveToGit/Layout|here]].
  
 
A few things will stay in subversion - currently websites, translations and manuals. It's possible they could move to Git later, but they won't be part of the mass migration.
 
A few things will stay in subversion - currently websites, translations and manuals. It's possible they could move to Git later, but they won't be part of the mass migration.
Line 35: Line 40:
  
 
==Setup git.kde.org==
 
==Setup git.kde.org==
{{Progress bar|40}}
+
{{Progress bar|100}}
 
'''Owner:''' Eike, Jeff, Sysadmin team
 
'''Owner:''' Eike, Jeff, Sysadmin team
  
 
'''Status:''' ''Progressing''
 
'''Status:''' ''Progressing''
  
: It [http://lists.kde.org/?l=kde-scm-interest&m=127612957219466&w=2 has been decided] to use gitosis + Redmine + reviewboard on our own servers rather than gitorious.org.  Sysadmin team is preparing git.kde.org for this.
+
: It [http://lists.kde.org/?l=kde-scm-interest&m=127612957219466&w=2 has been decided] to use gitolite + Redmine + reviewboard on our own servers rather than gitorious.org.  Sysadmin team is preparing git.kde.org for this.
  
 
==Write / update importing rules for svn2git==
 
==Write / update importing rules for svn2git==
{{Progress bar|5}}
+
{{Progress bar|35}}
 
'''Owner:''' see below - volunteers needed!
 
'''Owner:''' see below - volunteers needed!
  
 
'''Status:''' ''sho: ???, tumaix:started to read the docs, cryos: getting started [2010-01-06]''
 
'''Status:''' ''sho: ???, tumaix:started to read the docs, cryos: getting started [2010-01-06]''
  
:The importer is on gitorious.org as svn2git we have a set of rules to tell the importer what svn dirs turn into which git repos and those need constant updating whenever a new branch or tag or project is created. Currently the rules are mostly a rough draft, as seen by the large amount of rule-editing that had to be done for Konversation and Amarok. This has not been done for quite some time and so someone should rsync the svn repo run svn2git and fix the rules and importer whenever the import stops.
+
'''Note: more up to date information can be seen here: [[Projects/MovetoGit/Progress|Git Migration Progress]]
 +
'''
 +
 
 +
:The importer is on gitorious.org as svn2git we have a set of rules to tell the importer what svn dirs turn into which git repos and those need constant updating whenever a new branch or tag or project is created. The existing rules that have been used for past git migrations can be seen in [[https://projects.kde.org/projects/playground/sdk/kde-ruleset KDE ruleset]]  It also contains some helper scripts to rsync svn and such (which takes a lot of disk space, so be warned).
  
 
:This is a very big task, too big for one person; it's probably best to tackle it one module at a time
 
:This is a very big task, too big for one person; it's probably best to tackle it one module at a time
  
 
:To get started on a module, read [[Projects/MoveToGit/UsingSvn2Git|Using Svn2Git]]
 
:To get started on a module, read [[Projects/MoveToGit/UsingSvn2Git|Using Svn2Git]]
 
:TZander has done the koffice ruleset as of 2009-01-06
 
 
:Jpwhiting has finished (more or less) the kdeaccessibility ruleset 2010-01-24.
 
 
:aavci has done the k3b ruleset as of 2010-01-27
 
 
  
 
progress details:
 
progress details:
Line 70: Line 71:
 
|SC/kdeaccessibility
 
|SC/kdeaccessibility
 
|jpwhiting
 
|jpwhiting
|99
+
|100
|"more or less"?
+
|Done and migrated
 
|-
 
|-
 
|SC/kdeadmin
 
|SC/kdeadmin
|
+
|ruphy
 
|0
 
|0
 
|
 
|
 
|-
 
|-
 
|SC/kdeartwork
 
|SC/kdeartwork
|
+
|ruphy
 
|0
 
|0
 
|
 
|
Line 85: Line 86:
 
|SC/kdebase
 
|SC/kdebase
 
|
 
|
|0
+
|100
|
+
|Done and migrated
 
|-
 
|-
 
|SC/kdebindings
 
|SC/kdebindings
|
+
|pumphaus/Arno Rehn
|0
+
|100
|
+
|All written, converted and migrated
 
|-
 
|-
 
|SC/kdeedu
 
|SC/kdeedu
|cryos?
+
|
|?
+
|100
|update me!
+
|[[http://community.kde.org/KDE_Edu#Git_Migration]] Done
 
|-
 
|-
 
|SC/kdeedu/marble
 
|SC/kdeedu/marble
 
|jmho
 
|jmho
 
|100
 
|100
|Contains: trunk with moves (playground->kdereview->kdeedu), regular kde branches/tags and the following other branches: marble-0.4, gsoc-2009 and geodata-nt. Checking done: gitk --all, verify-git-from-svn
+
|Done and migrated
 
|-
 
|-
 
|SC/kdeexamples
 
|SC/kdeexamples
|
+
|ruphy
|0
+
|50
 
|
 
|
 
|-
 
|-
Line 115: Line 116:
 
|SC/kdegraphics
 
|SC/kdegraphics
 
|
 
|
|0
+
|100
|
+
|Done and migrated
 
|-
 
|-
 
|SC/kdelibs
 
|SC/kdelibs
 
|
 
|
|0
+
|100
|
+
|Done and migrated
 
|-
 
|-
 
|SC/kdemultimedia
 
|SC/kdemultimedia
Line 135: Line 136:
 
|SC/kdepim
 
|SC/kdepim
 
|tnyblom
 
|tnyblom
|95
+
|100
|Needs verification.
+
|Done and migrated
 
|-
 
|-
 
|SC/kdepim-runtime
 
|SC/kdepim-runtime
 
|tnyblom
 
|tnyblom
|95
+
|100
|Needs verification.
+
|Done and migrated
 
|-
 
|-
 
|SC/kdepimlibs
 
|SC/kdepimlibs
 
|tnyblom
 
|tnyblom
|95
+
|100
|Needs verification.
+
|Done and migrated
 
|-
 
|-
 
|SC/kdeplasma-addons
 
|SC/kdeplasma-addons
|
+
|asouza
|0
+
|100
|
+
|Done and migrated
 
|-
 
|-
 
|SC/kdesdk
 
|SC/kdesdk
Line 165: Line 166:
 
|SC/kdeutils
 
|SC/kdeutils
 
|jobermayr
 
|jobermayr
|95
+
|100
|coolo or mueller do not give me required information for old tags :-(
+
|Done and migrated
 
|-
 
|-
 
|SC/kdewebdev
 
|SC/kdewebdev
Line 175: Line 176:
 
|extragear/sdk/kdevelop
 
|extragear/sdk/kdevelop
 
| apaku
 
| apaku
| 95
+
| 100
| trunk and branches complete, need to cleanup tags from cvs days.
+
| Done and migrated
 
|-
 
|-
 
|extragear/sdk/kdevplatform
 
|extragear/sdk/kdevplatform
 
| apaku
 
| apaku
 
| 100
 
| 100
| done, all tags seem fine all branches are there
+
| Done and migrated
 
|-
 
|-
 
|extragear/sdk/kdevelop-plugins
 
|extragear/sdk/kdevelop-plugins
 
| nsams
 
| nsams
 
| 100
 
| 100
| done
+
| Done and migrated
 
|-
 
|-
 
|extragear/sdk/quanta
 
|extragear/sdk/quanta
Line 212: Line 213:
 
|0
 
|0
 
|
 
|
 +
|-
 +
|kdesupport/soprano
 +
|cgiboudeaux
 +
|100
 +
|Done and migrated
 +
|-
 +
|kdesupport/attica
 +
|cgiboudeaux
 +
|100
 +
|Done and migrated
 
|-
 
|-
 
|koffice
 
|koffice
 
|tzander
 
|tzander
|85
+
|100
|All but tags are done
+
|Done and migrated
 
|-
 
|-
 
|promo
 
|promo
|
+
|ruphy
 
|0
 
|0
 
|
 
|
Line 306: Line 317:
  
 
==Script for downloading virtual KDE hierarchies==
 
==Script for downloading virtual KDE hierarchies==
{{Progress bar|0}}
+
{{Progress bar|99}}
 
'''Owner''':  
 
'''Owner''':  
  
 
'''Status:'''  
 
'''Status:'''  
  
:Let's start over on this.
+
:we already have kdesrc-build, build-tool and mr: three good tools for managing repos.
what we already have: two build scripts for kde; kdesvn-build and build-tool.
+
what we want: an easy way for people to get large chunks of kde, without thinking about what urls the repos come from or having to look things up.
+
  
do kdesvn-build and build-tool satisfy this well enough?
+
Most people use kdesrc-build; it will neither eat babies nor kittens. it has options for updating everything or individual modules, can do fetch-only or build-only, etc..
or do we want a computer-readable file listing all the repos too?
+
Command-line options for updating the configuration would be a nice addition.
  
btw, scripty has its own list of repos already. it's just in a rather weird bash file.
+
TODO: details on mr and build-tool
 +
 
 +
note: scripty also has its own list of repos. it's just in a rather weird bash file.
  
 
'''Discussion:'''  
 
'''Discussion:'''  
  
As far as I can see, kdesvn-build is able to do it, it should be just a matter of providing a configuration. As I'm not using build-tool, I can't say anything about it. --jmho
+
As far as I can see, kdesrc-build is able to do it, it should be just a matter of providing a configuration. As I'm not using build-tool, I can't say anything about it. --jmho
  
 
'''Links'''
 
'''Links'''
[http://kdesvn-build.kde.org/]
+
*[http://kdesrc-build.kde.org/ kdesrc-build]
[[Projects/MovetoGit/MassCloneScript]]
+
*[[Projects/MovetoGit/MassCloneScript]]
[http://rubyforge.org/projects/build-tool/]
+
*[http://michael-jansen.biz/build-tool/ build-tool]
 +
*TODO: link to mr
  
 
==pre-receive hooks==
 
==pre-receive hooks==
Line 353: Line 365:
  
 
==Snapshot to read-only svn==
 
==Snapshot to read-only svn==
{{Progress bar|0}}
+
{{Progress bar|100}}
 
'''Owner:'''
 
'''Owner:'''
  
Line 364: Line 376:
 
:if we leave the docbook stuff in svn, we can avoid this a bit longer. --[[User:Chani|Chani]] 23:21, 12 November 2009 (UTC)
 
:if we leave the docbook stuff in svn, we can avoid this a bit longer. --[[User:Chani|Chani]] 23:21, 12 November 2009 (UTC)
  
==[[Development/Tutorials/Git|Techbase Documentation]]==
+
Scripty operates on a git clone of the repo's. No need for this item imho -- toma
 +
 
 +
==[[Development/Git|Techbase Documentation]]==
 
'''Owner:''' Chani, greeneg, - ''please help out!''
 
'''Owner:''' Chani, greeneg, - ''please help out!''
 
{{Progress bar|10}}
 
{{Progress bar|10}}
Line 370: Line 384:
 
:At least minimal documentation about how to checkout, how to request a merge needed, other git documentation and links to other git information would be very useful also.
 
:At least minimal documentation about how to checkout, how to request a merge needed, other git documentation and links to other git information would be very useful also.
  
:see the [[Development/Tutorials/Git|Git Tutorial Page]]. help wanted!!
+
:see the [[Development/Git|Central Git Page]]. help wanted!!
  
 
'''Discussion'''
 
'''Discussion'''
  
 
==Setup git mirrors for cloning==
 
==Setup git mirrors for cloning==
{{Progress bar|0}}
+
{{Progress bar|100}}
'''Owner:''' No one (help!)
+
'''Owner:''' sysadmin
 
:Re-purpose the anonsvn servers. This item might be a blocker.
 
:Re-purpose the anonsvn servers. This item might be a blocker.
 
'''Discussion'''
 
'''Discussion'''
 +
:sysadmin will add mirrors as needed and is prepared for it. -- toma
  
 
==Local pre-commit hooks==
 
==Local pre-commit hooks==
Line 392: Line 407:
  
 
==Website Branding==
 
==Website Branding==
{{Progress bar|2|text=(initial ideas on the table)}}
+
{{Progress bar|50|text=(initial ideas on the table)}}
 
'''Owner:''' ruphy
 
'''Owner:''' ruphy
  
Line 400: Line 415:
  
 
Is this section still necessary at all? Perhaps some branding has to be done for redmine or cgit, but I don't know. --jmho
 
Is this section still necessary at all? Perhaps some branding has to be done for redmine or cgit, but I don't know. --jmho
 +
 +
Neverendingo is looking at this as needed --toma
  
 
=Unscheduled & Open=
 
=Unscheduled & Open=
Line 413: Line 430:
  
 
==Account setup for Gitolite==
 
==Account setup for Gitolite==
{{Progress bar|0}}
+
{{Progress bar|100}}
  
 
'''Owner:''' ''sysadmin''
 
'''Owner:''' ''sysadmin''
Line 420: Line 437:
  
 
==post-update hooks==
 
==post-update hooks==
{{Progress bar|90}}
+
{{Progress bar|100}}
 
'''Owner:''' ''morice'' ''Ian Monroe''
 
'''Owner:''' ''morice'' ''Ian Monroe''
  
Line 428: Line 445:
 
We have a fairly complete set of post-update hooks now. See [http://gitorious.org/remotehook remotehook]. However, it would be nice to have a system that lives on the Gitorious server and/or requires less manual maintenance. But its certainly workable and no longer a blocker.
 
We have a fairly complete set of post-update hooks now. See [http://gitorious.org/remotehook remotehook]. However, it would be nice to have a system that lives on the Gitorious server and/or requires less manual maintenance. But its certainly workable and no longer a blocker.
  
 +
Working fine in the new setup, --toma
  
 
=Completed Tasks=
 
=Completed Tasks=
Line 586: Line 604:
  
 
jonas: domain name  
 
jonas: domain name  
 
ML: convert to SSH
 
  
 
chani: techbase docs for scripty  
 
chani: techbase docs for scripty  

Latest revision as of 17:17, 2 June 2012

This is the page for co-ordinating KDE's move to Git.

If you're interested in helping, you should join the kde-scm-interest@kde.org mailinglist and #kde-git on freenode.

Meetings are wednesdays, 19:30 UTC, in #kde-git.

New! The best way you can help us migrate

Contents

[edit] The Plan

KDE is moving to Git. We will be using gitolite + Redmine + reviewboard on our own servers.

In the summer of 2009, Amarok moved to Gitorious to test the waters and find problems that would affect KDE.

After it has been decided in Jun 2010 to use our own servers, Amarok and Konversation moved to git.kde.org/projects.kde.org to test the waters and find problems that would affect KDE.

Once those problems have been solved, all of KDE will be able to switch.

A full schedule for the git infrastructure can be found here.

[edit] Why?

Git offers many advantages over svn, including offline commits and much easier to keep a feature branch up-to-date. Many KDE developers are already using git-svn, but this tool has its limitations. We want to have the full power of Git available, and we have people willing to do the work necessary to migrate.

[edit] How?

When we move, KDE's svn repository will be migrated into several Git repos, all on git.kde.org. Main modules such as kdelibs and kdebase will each become one repository. Projects in extragear will each have their own repository. The projects.kde.org site will have a list (lists?) of all these repositories using the redmine project wiki. Scripts will be provided for downloading, say, all of extragear, so "moving" a project from kdereview to extragear would simply involve editing a file kept online that defined the location of projects. Details on the reasoning behind this layout is available here.

A few things will stay in subversion - currently websites, translations and manuals. It's possible they could move to Git later, but they won't be part of the mass migration.

All KDE developers will in principle be able to use their existing "svn" accounts. Developers using HTTPS ideally would request their HTTPS SVN account to be converted to SSH as that makes it easiest for the KDE sysadmins, but alternatively they can also just provide a public key. At some point the KDE sysadmins are going to send everybody with a HTTPS SVN account an email with a link to a web app to collect their key (see http://www.omat.nl/2010/06/13/sysamin-update-your-email-address/).

From the times when gitorious.org was the preferred hosting solution, a procedure to move a project from svn to gitorious.org can be found in Steps to follow for Moving. Many points probably still apply, but have to be updated.

[edit] Blockers

Tasks that need to get done before we can migrate

[edit] Setup git.kde.org

100% completed (estimate)

  

Owner: Eike, Jeff, Sysadmin team

Status: Progressing

It has been decided to use gitolite + Redmine + reviewboard on our own servers rather than gitorious.org. Sysadmin team is preparing git.kde.org for this.

[edit] Write / update importing rules for svn2git

35% completed (estimate)

  

Owner: see below - volunteers needed!

Status: sho: ???, tumaix:started to read the docs, cryos: getting started [2010-01-06]

Note: more up to date information can be seen here: Git Migration Progress

The importer is on gitorious.org as svn2git we have a set of rules to tell the importer what svn dirs turn into which git repos and those need constant updating whenever a new branch or tag or project is created. The existing rules that have been used for past git migrations can be seen in [KDE ruleset] It also contains some helper scripts to rsync svn and such (which takes a lot of disk space, so be warned).
This is a very big task, too big for one person; it's probably best to tackle it one module at a time
To get started on a module, read Using Svn2Git

progress details:

repo owner % comments
SC/kdeaccessibility jpwhiting 100 Done and migrated
SC/kdeadmin ruphy 0
SC/kdeartwork ruphy 0
SC/kdebase 100 Done and migrated
SC/kdebindings pumphaus/Arno Rehn 100 All written, converted and migrated
SC/kdeedu 100 [[1]] Done
SC/kdeedu/marble jmho 100 Done and migrated
SC/kdeexamples ruphy 50
SC/kdegames jobermayr 95 coolo or mueller do not give me required information for old tags :-(
SC/kdegraphics 100 Done and migrated
SC/kdelibs 100 Done and migrated
SC/kdemultimedia eean 0
SC/kdenetwork grundleborg 0
SC/kdepim tnyblom 100 Done and migrated
SC/kdepim-runtime tnyblom 100 Done and migrated
SC/kdepimlibs tnyblom 100 Done and migrated
SC/kdeplasma-addons asouza 100 Done and migrated
SC/kdesdk 0
SC/kdetoys 0
SC/kdeutils jobermayr 100 Done and migrated
SC/kdewebdev 0
extragear/sdk/kdevelop apaku 100 Done and migrated
extragear/sdk/kdevplatform apaku 100 Done and migrated
extragear/sdk/kdevelop-plugins nsams 100 Done and migrated
extragear/sdk/quanta nsams 99 done
extragear/utils/krecipes santa 85 Branches are done, I'm working on tags.
extragear/*/* xx expand the *'s later (let's focus on the base modules first)
kde-common mattr 75 analyzing import history
kdesupport 0
kdesupport/soprano cgiboudeaux 100 Done and migrated
kdesupport/attica cgiboudeaux 100 Done and migrated
koffice tzander 100 Done and migrated
promo ruphy 0
quality 0
tests 0

[edit] Requirements of KDEPIM and KDAB

90% completed (estimate)

  

Owner: Stephen Kelly

Status: Proposed workflow identified. Partially depends on KDE policies regarding branches and merging. Gathering estimates for porting of tooling from svn to git. People unfamiliar with the tool are starting to learn to use it.

Estimated completion date: End of May.

Summary of issues

  • Clean slate
    • The existing backlog of commits which need to be merged or ported to trunk needs to be empty before the change to git so that nothing gets lost. This is a lot of work and will take time. Estimate 10 calendar weeks.
  • Technical difficulties and limitations.
    • Up to KDE 3.5 there was one kdepim module. For the KDE4 cycle, this was split into kdepimlibs and kdepim. For the above mentioned merging to be possible, it makes sense for both to be in the same git module. This poses extra difficulty to the svn2git script.


Email threads

http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=64069

Resolved Issues


  • Branch maintenance workflow Resolution: http://thread.gmane.org/gmane.comp.kde.scm-interest/1310
    • KDAB maintains several branches of legacy versions of KDE for enterprise customer deployments. Enterprise 3.5 Enterprise 4 (based on KDE 4.2). The current KDEPIM trunk known as Enterprise 5 and is Akonadi based.
    • Periodically (weekly or so), tags are created from the enterprise branches with bugfixes. http://websvn.kde.org:80/tags/kdepim/ Customers can download the tagged versions with the latest updates. Fixes are merged from the Enterprise 3.5 branch, and into trunk (which sometimes involves a lot of work, as the fix must be ported to Akonadi). Additionally, fixes get merged in the other direction. From official KDE modules into the Enterprise branches.
    • Some fixes from Enterprise 3.5 should not be merged into Enterprise 4 for reasons such as no longer being reproducible. Some fixes do not get merged for a long time because they require so much work that porting the fix or feature is deffered. There needs to be a list of commits which should never be merged (blocked commits), and commits which should be merged, but have not been merged yet. The tool svnmerge is used to facilitate this. svnmerge uses svn properties to maintain lists of commits that are blocked and that have already been integrated. See for example the svn-blocked and svn-integrated properties here: http://websvn.kde.org:80/trunk/KDE/kdepim/. The lists of commits available to be merged into the various branches are here: http://www.kdab.com/~thomas/avail/
    • There needs to be a way in git to keep track of what commits have been merged, what commits need to be merged, and what commits are blocked. There needs to be a way of merging only specific commits from a branch, but not all, and not blocked commits. Proposed solutions:
      • git cherry-pick allows 'merging' of individual commits, but does not record where the commits came from. Instead it creates a new commit without any reference to where it came from. This alone is unsuitable.
      • branch per fix. This would lead to an explosion of branches which is not a problem in git as all commits are branches. It may make gitk un-navigatable. There would need to be a naming convention such as komo-merge-<fixname> for branches which should be merged. The commands git checkout 4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge) and git checkout enterprise4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge) and git checkout master && git merge $(git branch -a | grep -E ^origin/komo-merge). That could of course be optimized, but gets the point across. If the code has changed so much that the branch is unmergable, but the fix still needs to be in trunk, the system breaks down.
      • Custom git command with flat text files representing the same information as svnmerge, that is lists of blocked and integrated commits. This is most likely to be a workable solution, possibly together with conventional branch naming.
  • Internal Tools and external customer tools and workflows
    • KDAB is a consumer of KDE software, but also has downstream customers fetching software from where it is developed. That is, KDE SVN. For example packages are created from the tags in tags/kdepim. Some of these downstreams are less close to KDE and depend on current workflows. If KDE SVN is not the place to get those updates anymore, this needs to be communicated to those downstreams, and the tools updated. Estimate 1 week to port the tools.
      • Internally used tools have been updated and are now being used to access git repos such as dbus.
  • Other commitments
    • Project deadlines and other commitments prevent the possibility of blocking off time to work on git migration when so many other things need to be done which have milestones separate to KDE cycles. The required work to convert to git can't be prioritized as highly, and so will take more time.
      • Most of the technical work regarding migration of kdepim repos has been completed by community member Torgny Nyblom.
  • Tool knowledge
    • People who don't currently know how to use git need to get familiar with it so that transitioning will be nearly seamless, and not result in too much development slowdown.
      • Workshops and use of git-svn have been used to bring developers up to speed on how to use git at some level.

[edit] Nice to have before the migration

[edit] Push log

100% completed (estimate)

  

Owner: sysadmin

Status: finished

It's a push log, similar to a local repository's reflog.


For every push, log:

- who pushed (not the Unix username, which will be "git")
- which branch heads changed (what from, what to)
- which tags were created
- the state of all other branches and tags

Just use git commit-tree with the empty tree and save everything in the commit message, one after the other.


Gitolite includes this functionality inbuilt to itself, although all repositories are logged in the same file - bcooksley


[edit] Script for downloading virtual KDE hierarchies

99% completed (estimate)

  

Owner:

Status:

we already have kdesrc-build, build-tool and mr: three good tools for managing repos.

Most people use kdesrc-build; it will neither eat babies nor kittens. it has options for updating everything or individual modules, can do fetch-only or build-only, etc.. Command-line options for updating the configuration would be a nice addition.

TODO: details on mr and build-tool

note: scripty also has its own list of repos. it's just in a rather weird bash file.

Discussion:

As far as I can see, kdesrc-build is able to do it, it should be just a matter of providing a configuration. As I'm not using build-tool, I can't say anything about it. --jmho

Links

[edit] pre-receive hooks

50% completed (estimate)

  

Owner: volunteers needed!!

  • Line endings and encodings

Discussion: this got accidentally marked as done or something, but it's not.

This has now been ported to Git - bcooksley

Note however that it doesn't look for a .gitattributes file yet - patches welcome ( see sysadmin/repo-management on git.kde.org )

Notes: > > As for line-endings, be careful because Git is different from Subversion. > > different how?

Just ensure that all files are stored as LF only, except if there's a .gitattributes file saying "-crlf" (i.e., allow it to have CRLF).


[edit] Snapshot to read-only svn

100% completed (estimate)

  

Owner:

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

Discussion

Could be done with a git-svn gateway presumably? -Mike Arthur 19/10/2009 16:04
if we leave the docbook stuff in svn, we can avoid this a bit longer. --Chani 23:21, 12 November 2009 (UTC)

Scripty operates on a git clone of the repo's. No need for this item imho -- toma

[edit] Techbase Documentation

Owner: Chani, greeneg, - please help out!

10% completed (estimate)

  

At least minimal documentation about how to checkout, how to request a merge needed, other git documentation and links to other git information would be very useful also.
see the Central Git Page. help wanted!!

Discussion

[edit] Setup git mirrors for cloning

100% completed (estimate)

  

Owner: sysadmin

Re-purpose the anonsvn servers. This item might be a blocker.

Discussion

sysadmin will add mirrors as needed and is prepared for it. -- toma

[edit] Local pre-commit hooks

0% completed (estimate)

  

Owner: argonel

A set of recommended local hooks that give useful warnings could be nice to have.

Discussion ...on the other hand, if we get a lot of bikeshedding about what hooks, then it won't be so nice. so I'd put this in the "very optional" pile. --Chani 19:10, 16 December 2009 (UTC)

[edit] Post-migration Issues

[edit] Website Branding

50% (initial ideas on the table)

  

Owner: ruphy

KDE Gitorious should be branded accordingly, and should be reachable from git.kde.org as well as kde.gitorious.org

Discussion

Is this section still necessary at all? Perhaps some branding has to be done for redmine or cgit, but I don't know. --jmho

Neverendingo is looking at this as needed --toma

[edit] Unscheduled & Open

[edit] Allow tagging without involving sysadmins

100% completed (estimate)

  

Owner: sysadmin

Gitolite allows sysadmin to permit certain people on certain repos only to manage both branches and tag without needing force push rights.

Discussion

[edit] Account setup for Gitolite

100% completed (estimate)

  

Owner: sysadmin

Accounts for existing SVN accounts which use SSH for access have been automatically granted access to Gitolite. Those who are still using HTTPS need to file a sysadmin bug to change their SVN account to SSH and will recieve Git access automatically.

[edit] post-update hooks

100% completed (estimate)

  

Owner: morice Ian Monroe

  • License checker

Discussion: We have a fairly complete set of post-update hooks now. See remotehook. However, it would be nice to have a system that lives on the Gitorious server and/or requires less manual maintenance. But its certainly workable and no longer a blocker.

Working fine in the new setup, --toma

[edit] Completed Tasks

[edit] Get rid of svn:externals

100% completed (estimate)

  

Owner: David Faure

Status: ???

not possible with git, broken by design.

Discussion

Exists, but ignorable:

  • kdesupport shared-desktop-ontologies (temporary)
  • playground/utils strigi-chemical/test/ctfr
  • playground/devtools kdevelop4-extra-plugins/php/parser/generated/kdevelop-pg-qt
  • playground/devtools kdevelop4-extra-plugins/python/parser/generated/kdevelop-pg-qt
  • playground/devtools kdevelop4-extra-plugins/qmake/parser/generated/kdevelop-pg-qt
  • playground/devtools kommander-plugins/database3/admin
  • playground/devtools kommander-plugins/database/admin
  • playground/devtools kommander-plugins/datetimefuncs/admin
  • playground/devtools kommander-plugins/htmlpart/admin
  • playground/devtools kommander-plugins/httpform/admin
  • playground/devtools kommander-plugins/kparts/admin
  • playground/devtools kommander-plugins/qtactionproxy/admin
  • playground/devtools kommander-plugins/timewidget/admin
  • playground/devtools kommander-plugins/webkit3/admin
  • playground/devtools kpackagemaker/admin

[edit] EBN

95% completed (estimate)

  

Owner: drf

Status: Amarok has EBN checks

EBN's krazy checks currently run on kde's svn repo; it needs upgrading to download and check our git repos too.
This would be easier if there was a repo-list that EBN could parse, as it can no longer just svn up to get everything.

[edit] Talk to people using other distros about git

100% completed (estimate)

  

Owner: Sebas, Eike

Discussion

  • Gentoo: They seem to be prepared for moving their live SVN packages to git; their package manager has easily-reusable classes to fetch from an SCM and moving the ebuilds to using the git class rather than the SVN class should be easy. Positive comments to that end from people in #gentoo-kde.
  • Fedora: Some unhappyness about git because SVN allows them to remotely produce a diff between two SVN URLs (or two revisions of one and the same URL) without making a checkout first, while git requires making a clone. Kevin Kofler (IRC nick Kevin_Kofler, #fedora-kde) says this will make their packager work harder.
  • Debian: Is indifferent about the SCM switch.

[edit] Post Update hooks

100% completed (estimate)

  

Owner: morice, johan, mattr

List of scripts needed:
  • BUG/CCMAIL
  • email/CIA
Gitorious needs to provide a way for hooks to be called; KDE needs to write said hooks.

Discussion

There is a branch of gitorious called web-hooks http://gitorious.org/gitorious/mainline/commits/web-hooks --Panagiotis Papadopoulos 1 November 2009
Same situation as commit emails. I can do it but it doesn't scale well and a Gitorious-supported solution would be nicer. --eean 16:07, 12 November 2009 (UTC)

[edit] Reviewboard

100% completed (estimate)

  

Owner: darktears

This should be easily done with Gitorious web interface and merge requests actually.

Discussion

but reviewboard has features gitorious (right now) doesn't, like commenting on specific lines and not having to set up a merge request. --chani
Also email notifications when someone reviews are needed --thomasz
We're working on this for someone else right now, so pretty soon --johan-s
I consider the latest changes to gitorious to finish this. If more reviewboard features are still needed, and git supports reviewboard, I think this is something we can look at doing post-conversion. --Ian Monroe


[edit] Gitorious Needs a feature to disable merge request emails for certain repos

100% completed (estimate)

  

Owner: Gitorious

Have a sensible system for merge request emails. This is now in place - you can join groups, chose whether to have emails on a per repo basis, etc.

[edit] SSH blocked in corporations and universities.

100% completed (estimate)

  

Owner: Unknown

Some universities tend to block the SSH port. There should be a workaround to use SSH on some different port. github.com already runs a SSH server on port 443. But that assumes you are using a proxy. It has been found that this hasn't worked with a lot of people, especially those who have a direct connection to the internet ( so some transparent blocking by the ISP ). It would be great if (almost) every KDE developer were to be asked to check if other ports work before KDE made the switch. Otherwise there could be an automated email where the git patches could be sent, and appropriately patched to the right location too.

Discussion

http://blog.gitorious.org/2009/10/20/stuck-behind-a-firewall/, and there's always been HTTP cloning (although the current impl. in Git is a bit on the slow side) --johan-s


[edit] Talk to windows guys about git.

100% completed (estimate)

  

Owner: aseigo

Discussion

They aren't huge fans of git, but are using it. They require a single mainline and can't cope with multiple branches. Otherwise, it's workable, even if it will take an adjustment period.

[edit] pre-commit hooks

100% completed (estimate)

  

Owner: (unknown)

acltest, docbook, EOL/UTF-8
A web hook isn't good enough for these because they have to run and return whether to allow the push, for every single push to every KDE repo.


Discussion

gitorious guys said they *might* be willing to allow a few scripts on their server for KDE as a special exception, iirc. --chani
Yes, at least for basic things, heavier things like doc building would probably have to be mirrored (goes for pre/post) --johan-s
It turns out that acl and docbook might not be needed so long as web and docs/ stuff stays in svn.
Here's where to find the current scripts - http://websvn.kde.org/trunk/kde-common/svn/hooks/ --Argonel 23:06, 11 November 2009 (UTC)
So: this is actually done because it needs no longer to be done? (boud)
Apparently, so; moving to complete. (aseigo)

[edit] other notes

[edit] kde-common/accounts

Someone said: KDE accounts file is no longer necessary---used for mapping svn ID -> email, but we have that now from Gitorious. Answer from David Faure: I strongly disagree. We still need a KDE accounts file. This is very useful for finding people's email addresses, and having an overview on the number of active kde contributors; and if we keep it we can even have a kdepim resource again for filling an addressbook from it, for completion in kmail's composer (so you can write to any other kde contributor by just typing his/her name). It's also used for populating automatically the kde-cvs-announce mailing-list, for announcements. kde-common/accounts is our family tree (well, list), let's not get rid of it.

Here's my proposal for a kde-common/accounts replacement for the git era: We write a post-receive hook that looks at every commit and records all known email addresses for a given real name as well as the commit hash and date of when an address was last encountered. We can then present that data in the form of a file like kde-common/accounts, or write a web interface to query it (with nice links to the commits on Gitorious, etc.) --Eike (Sho_ on IRC)

To clear up possible confusion: The author information for a given commit is baked into the commit object itself, and comes from the configuration of the git repository it was created in. It is unrelated to any Gitorious account. Due to the distributed nature of Git, the one who uses his Gitorious account to push a commit need not be the same who created it. If Developer A creates a commit in his local clone and Developer B fetches it into his local clone directly from Developer A's machine and then pushes it into the public repo, the repo will only show a commit from Developer A. The Gitorious website will show that Developer B has pushed up a commit from Developer A, but that data is not contained in the repository. Thus collecting only Gitorious accounts and their mail addresses is insufficient. --Eike

[edit] Random

http://mail.kde.org/pipermail/dot-stories/2005-May/000509.html might be a good guide on what docs we need.


some of this stuff was from the list from GCDS that was in this email http://markmail.org/message/u6eqfjece7fibfyo

[edit] IRC Meetings

[edit] jobs

TODO merge this with the todolists above

michael jansen: talking to kdesvn-build/mpyne

--Done? -> http://kdesvn-build.kde.org/releases/kdesvn-build-1.10.php -- Panagiotis Papadopoulos 1 November 2009
Yes, but the __kdesvn-build-remote used in the impl isn't pleasant for users already on git so it still needs more work for them. Mpyne 20:32, 11 November 2009 (UTC)

jonas: domain name

chani: techbase docs for scripty

sebas/lydia/leo: communication with teams! tell people! keeping track that everything is being done.


This page was last modified on 2 June 2012, at 17:17. This page has been accessed 61,453 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal