[Kde-scm-interest] Migration of KDESDK to git, finally? :)
Josef Weidendorfer
Josef.Weidendorfer at gmx.de
Tue May 8 16:03:18 UTC 2012
Hi,
thanks for getting this started again!
Am 08.05.2012 17:11, schrieb Friedrich W. H. Kossebau:
> KDESDK currently is still in svn. At least for Okteta I would like to have
> a move from svn to git as soon as possible.
>
> While there have been two threads about this on this list,
> "migration of kdesdk to git - status?" from 18.12.2010 and
> "Idea: Converting KDESDK incrementally" from 28.03.2011, so far
> nothing has happened, besides Kate and kdesrc-build having moved out
> of KDESDK to other modules. I would like to change that and have something
> happening :)
>
> The gist from the threads is that
> * the KDESDK module should be split into separate repos, as the single
> submodules do not have anything in common, like libs or stuff
Yes.
> * the whole of KDESDK should be moved to git in one step, to reduce the mess
> for release managers, packagers and friends
Yes.
> Anyone disagrees?
>
> Some brave people seem to have prepared set of rules for all the components
> of the KDESDK module (thanks to them), see
> https://projects.kde.org/projects/playground/sdk/kde-
> ruleset/repository/revisions/master/show/kdesdk
Ah, nice. I didn't know.
I do not really know the syntax for the rules, but at least for
kcachegrind there are no special (feature-)branches, and everything
within the kcachegrind/ directory is self-contained (apart from
translation/documentation). So the migration should be straight-forward.
> What is the state of these rules? Can the result be checked somewhere?
> Niko Sams, in the thread "migration of kdesdk to git - status?" as referenced
> above you also talked about having prepared rules, are they in some way
> integrated in what is in the repo linked above?
>
> Who are the current maintainers of all the submodules in KDESDK? I tried to
> put all in cc: which looked like the one, see also below who I listed
> for each submodule.
>
> Looking through KDESDK I wonder what should end up in a separate git repo
> and what not.
>
> Standalone programs:
> * cervisia - Christian Loose
> * kcachegrind - Josef Weidendorfer
> * kompare - Kevin Kofler
> * lokalize - Nick Shaforostoff
> * okteta - myself :)
> * umbrello - umbrello devs
> Surely one repo per program, right?
Looks good.
For the rest, I do not really have an opinion.
Cheers,
Josef
> Plugins, grouped by type:
> * dolphin-plugins
> svn -Peter Penz
> hg - Vishesh Yadav
> git - Sebastian Doerner
> bazaar - Jonathan Riddell
> * kioslave
> perldoc - Michael Pyne?
> svn - Mickael Marchand?
> * strigi-analyzer
> diff - Laurent Montel/Jakub Stachowski
> po - Montel Laurent/Nick Shaforostoff/Jos van den Oever
> ts - Montel Laurent/Jakub Stachowski
> xlf - Albert Astals Cid
> One repo per plugin? One repo per type?
>
>
> Development utils for KDE developers:
> * kapptemplate - Anne-Marie Mahfouf
> * kdeaccounts-plugin - Carsten Pfeiffer?
> * kdepalettes - ? (and still useful? nothing build/installed here)
> * kmtrace - seems unmaintained
> * kpartloader - David Faure
> * kprofilemethod - David Faure
> * kstartperf - Geert Jansen
> * kuiviewer - Benjamin C. Meyer
> * poxml - uh, no license headers! (Albert Astals Cid)
> * scripts - lots of kde devs
> Lots of small tools/helpers, basically not useful for anyone outside
> KDE development. Dump in one repo?
>
> I also wonder if these utilities here should not be split out into a separate
> module, or the other way round, if all the "real" programs and plugins
> should not make up a new module called "devtools"/"kdedev" or whatever,
> so the module with the "real" products can be better promoted to users
> outside of the group of KDE developers.
> And kapptemplate could also move to the module kdeexamples perhaps, as kind
> of code-to-copy/start-from?
>
>
> Completely excluded from build are:
> * kspy - Richard Moore
> * kunittest - Jeroen Wijnhout
> * scheck - Maksim Orlovich/Ryan Cumming
> These should be moved to tags/unmaintained in svn in any case?
>
>
> And while I have the attention of lots of KDESDK developers, would you mind
> if I take over the role as coordinator of KDESDK from Matt (in case his offer
> is still up) and mess^Wtry to clean-up the module a little?
>
> Cheers
> Friedrich
>
More information about the Kde-scm-interest
mailing list