Projects/MovetoGit

< Projects
Revision as of 18:11, 5 March 2010 by Steveire (Talk | contribs)

Jump to: navigation, search

Contents

Blockers

Tasks that need to get done before we can migrate

SLA for gitorious.org

30% completed (estimate)

  

Owner: aseigo, frank

Status: Progressing well; will take a while

The SLA terms need to be documented as well as who will be footing the bill, if any. TZander has talked to Shortcut AS and sent the relevant information (eg cost) to the KDE eV board.
aseigo and Frank (and someone?) had a meeting with Shortcut people during tokamak. They asked for a rather large sum of money; negotiations are continuing, but we might want to consider hosting our own server...

Write / update importing rules for svn2git

0% completed (estimate)

  

Owner: see below - volunteers needed!

Status: sandsmark: stuck on a svn2git bug. 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.
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
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:

repo owner % comments
SC/kdeaccessibility jpwhiting 99 "more or less"?
SC/kdeadmin 0
SC/kdeartwork 0
SC/kdebase 0
SC/kdebindings 0
SC/kdeedu cryos? ? update me!
SC/kdeexamples 0
SC/kdegames tumaix? ? update me!
SC/kdegraphics 0
SC/kdelibs 0
SC/kdemultimedia eean 0
SC/kdenetwork grundleborg 0
SC/kdepim tnyblom 0 Just getting started Help needed.
SC/kdepimlibs tnyblom 0 Just getting started Help needed.
SC/kdeplasma-addons 0
SC/kdesdk mattr 0 just starting
SC/kdetoys mattr 0 just starting
SC/kdeutils 0
SC/kdewebdev 0
extragear/sdk/kdevelop apaku 85 Misses history from KDE3.3 and older (KDevelop3.2), probably something with layout-changes, might need recurse-action but don't know how to do it.
extragear/sdk/kdevplatform apaku 100 done, all tags seem fine all branches are there
extragear/*/* xx expand the *'s later (let's focus on the base modules first)
kde-common mattr 0 just starting
kdesupport 0
koffice tzander 100
promo 0
quality 0
tests 0

Requirements of KDEPIM and KDAB

10% completed (estimate)

  

Owner: till (To be reassigned)

Status: Requirements of tools and for workflow identified. Someone from KDAB will be nominated to co-ordinate and communicate specific requirements

Summary of issues

  • Branch maintenance workflow
    • 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.
  • 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.
  • 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.
    • 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.
  • Other commitments
    • Project deadlines and other commitments prevent the possiblity 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.
  • 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


KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal