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 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
