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). Ciao -- Luigi _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
