[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Proposal to improving KDE Software Repository Organization
From: Luigi Toscano <luigi.toscano () tiscali ! it>
Date: 2015-08-16 21:36:33
Message-ID: 55D10261.1020303 () tiscali ! it
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic