git organisation for frameworks

[Allen Winter]

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 
> projects.kde.org 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 projects.kde.org 
> 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 https://projects.kde.org/projects/frameworks 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