Proposal to improving KDE Software Repository Organization
Ben Cooksley
bcooksley at kde.org
Tue Aug 18 11:27:39 BST 2015
On Mon, Aug 17, 2015 at 9:36 AM, Luigi Toscano <luigi.toscano at tiscali.it> 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).
Note that we won't be pulling any form of metadata for any structure
or organisation from Phabricator.
It'll be stored in a separate file and referenced appropriately.
As for Phabricator, i'd prefer using <Group> and <Product> projects to
organise things. You can then execute searches for all repositories
that are in a given set of projects.
eg: Kdenlive would be in #Extragear and #Multimedia. So you could find
all #Multimedia applications by searching for repositories which
belong to that project (and so forth).
Subprojects are not necessary here from my perspective. Subprojects
become useful when you have an overall project (see Plasma / Krita for
instance) which have the need for several boards to organise their
work - and thus have several projects.
>
> Ciao
> --
> Luigi
Regards,
Ben
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel at kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
More information about the kde-core-devel
mailing list