Idea: Converting KDESDK incrementally

Anne-Marie Mahfouf annemarie.mahfouf at
Tue Mar 29 09:33:00 CEST 2011

On Monday, March 28, 2011 10:48:11 PM Sebastian Dörner wrote:
> Hi,
> KDESDK is still using svn up to now and there doesn't seem to be much
> progress to make the transition for the whole repository. Also see the
> brief discussion on December 18th on kde-scm-interest.
> I guess one of the reasons is that KDESDK is rather an ensemble of
> individual sub-projects than one coherent module, so there is nobody who
> knows all the code and its history (correct me if wrong). Also, as
> stated in the a. m. discussion, the current maintainer doesn't have time
> to do it.
> I wonder if it would be feasible/sensible to do the conversion
> incrementally. In this model, people feeling responsible for parts of
> KDESDK write rules for their part and move the part to git individually.
> This would require them to know the history only for their part (which
> they certainly do) instead of knowing the history of whole kdesdk (which
> they less likely do).
> E.g. I would feel competent to write rules for kdesdk/dolphin-plugins,
> but don't know anything about the rest.
> Is there anything that makes this proposal a bad idea? How does it align
> with release management? Possibly, at the time of 4.7 parts of KDESDK
> would be in git and other parts still in svn.
> (Immediate cause for this mail is upcoming GSoC, where I would prefer
> dolphin-plugins in a git repository for consistency with rest of dolphin
> and for easier branching.)
> Cheers,
> Sebastian

I suggest we wait until the KDE-Edu module is done (this week-end) and from 
Monday next week we can start working on KDEsdk. It would be a good idea to 
check the status of the apps in there and to list those that are unmaintained 
beforehand and contact the maintainers. I don't know half of them personally! 
I am KAppTemplate maintainer and I am in favor of keeping a kdesdk module in 
git, with all apps building separately. I can write the rules for 
Having stuff in svn and git will be a mess. For the release packager we need to 
keep things sane and coherent.

I'd be happy to help in any way from next Monday,


More information about the release-team mailing list