Proposal to improving KDE Software Repository Organization

[David Faure]

On Sunday 16 August 2015 23:36:33 Luigi Toscano wrote:
> David Faure ha scritto:
> > On Sunday 16 August 2015 13:51:29 Michael Pyne wrote:
> >> There's no reason even with our current build metadata that we'd *have* to 
> >> have project hierarchies, as long as each underlying git repository name 
> >> remains unique. It might even make things easier since there would be no way 
> >> for a sub-path in our project hierarchy (such as kde/kdelibs/kactivities) to 
> >> mask a git repository name (kdelibs in this case).
> > 
> > Ben and I discussed it today and we think there is usefulness in one level of subtree within the
> > Applications product, to be able to keep the 'groups' like kdegraphics, kdemultimedia etc. which
> > are useful in order to have a maintainer per 'group' (as reinforced by the release team recently).
> > 
> > But yes, only one level, and AFAICS only useful in Applications.
> > kactivities (to pick your example) would be "at the root of" Frameworks, no sub-path needed.
> > 
> Does it mean a giant big blob for extragear and playground? Translation-wise,
> having the 'groups' is really useful to not get lost.
> 
> Also, when phabricator support subproject, using groups would be useful again
> to not have a big blob of projects (it was one of the few complains I recorded
> for phabricator, the big list of projects).

OK, so more products with repos organized in sub-paths, makes sense to me.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5