git organisation for frameworks

Allen Winter winter at
Sun Dec 22 20:07:55 UTC 2013

On Thursday, December 05, 2013 08:49:29 PM David Faure wrote:
> We're almost ready to split up kdelibs into a bunch of separate git modules, 
> the upcoming "frameworks" in KF5.
> One question that came up is where these modules should end up in the 
> hierarchy.
> Currently we have the following toplevel "components" in kde_projects.xml:
>   <component identifier="kdereview">
>   <component identifier="sysadmin">
>   <component identifier="calligra">
>   <component identifier="playground">
>   <component identifier="unmaintained">
>   <component identifier="qt">
>   <component identifier="koffice">
>   <component identifier="qt5">
>   <component identifier="repo-management">
>   <component identifier="kde-build-metadata">
>   <component identifier="kde">
>   <component identifier="others">
>   <component identifier="extragear">
>   <component identifier="websites">
>   <component identifier="kdesupport">
> and the KDE SC release is all of the component "kde".
> Given that frameworks will (might?) have a different release schedule than 
> workspace and apps, I think it would make sense to use a new toplevel 
> component "frameworks" for all frameworks.
> E.g. karchive will be in frameworks/karchive, in terms of 
> organization.
> Any objections?
> Seems clear to me, but Ben wanted to make sure before we proceed :)

How about if we group all the current frameworks projects into a kdelibs category?

Eventually we'd have a category for plasma, kdepim, etc.

the git urls wouldn't change, only the logical grouping would in the projects database.
so at the level we would have kdelibs, kdepim, plasma, etc, etc

essentially I'm advocating we re-create the concept of modules under the frameworks component.

in order to reduce clutter and group projects logically

More information about the release-team mailing list