[Kde-imaging] Re: Git migration for 2.0.0 + code components re-structuring...

[Gilles Caulier]

I propose a better code dir re-structuring : a lead
"digikam" root folder, including a "core" dir hosting current root
digikam dir. All other guest codes still on root "digikam" folder.

digikam/
    \--kipi-plugins
    \--libkmap
    \--libkface
    \--core/
           \--cmake/
           \--data/
           \--databaseserver/
           \--digikam/
           \--imageplugins/
           \--kioslave/
           \--libs/
           \--project/
           \--showfoto/
           \--tests/
           \--themedesigner/
           \--utilities/

like this, to synchronize digikam as well with a separate branch, it's
more easy. all is in core sub-dir.

your viewpoints ?

Gilles Caulier

2010/12/9 Gilles Caulier <caulier.gilles at gmail.com>:
> Hi all,
>
> If you fell kde development mailing list thread, recently a lots of
> project has started svn to git migration.
>
> I think we can plan to do it with digiKam and kipi-plugins code 2.0.0,
> and let's 1.x code to svn to be able to release bug-fixes only 1.8.0
> and perhaps 1.9.0, as i plan here :
>
> http://www.digikam.org/drupal/about/releaseplan
>
> The disadvantage to move svn Gosc2010 branch to git is the difficulty
> to synchronize with trunk code automatically. This is why after
> digiKam 1.7.0, only small bug-fixes must be applied to 1.x code.
>
> The documentation to process svn to git migration is here :
>
> http://techbase.kde.org/Projects/MovetoGit
>
> Andi, I remember that you have been volunteer in the past to process
> git migration. Right ?
>
> Other important point, if to restructure software components to
> simplify life of developers, users, packagers.
>
> A lots of peoples ask me to remove kdegraphics/libs dependency, which
> increase complexity to upgrade these shared libraries in some cases.
>
> The reasons why we share libraries is to solve common dependencies
> between kipi-plugins and digiKam (libkdcraw and libkevix2)
>
> Libkipi is more complex stuff because it's shared with others
> photo-management softwares (gwenview, kphotoalbum)
>
> Now, with 2.0.0, the complexity will be increased again with new
> libkface and libkmap.
>
> Why not to use Git migration to re-structure digiKam and kipi-plugins
> components ?
>
> This is my proposal : make a digiKam packaging including current
> digiKam + kipi-plugins + libkface + libkmap. The root dir contents of
> digiKam will become something like that :
>
> digikam/
>  \--cmake/
>  \--data/
>  \--databaseserver/
>  \--digikam/
>  \--imageplugins/
>  \--kioslave/
>  \--libs/
>  \--project/
>  \--showfoto/
>  \--tests/
>  \--themedesigner/
>  \--utilities/
>  \--kipi-plugins
>  \--libkmap
>  \--libkface
>
> look 3 last line of this tree...
>
> kipi-plugins will still undependant of digiKam core and installed as
> well, as now. i18n rules still also the same.
>
> About libkface, libkmap, it will work as kipi-plugins : it stand alone
> shared librared installed on the system.
>
> This will solve the huge puzzle for us, digiKam & co developpers. As
> we maintain this code...
>
> What do you think about ?
>
> Gilles Caulier
>