From kde-core-devel Mon Aug 17 08:15:36 2015 From: David Faure Date: Mon, 17 Aug 2015 08:15:36 +0000 To: kde-core-devel Subject: Re: Proposal to improving KDE Software Repository Organization Message-Id: <28806197.45fphmU6lv () asterix> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=143979935825893 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@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5