[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:       Ben Cooksley <bcooksley () kde ! org>
Date:       2015-08-18 10:35:09
Message-ID: CA+XidOGD7O7CwjO-EOtM8ywcvfKsOAgJmAXnCrKJ4senL33o7A () mail ! gmail ! com
[Download RAW message or body]

On Mon, Aug 17, 2015 at 8:15 PM, David Faure <faure@kde.org> wrote:
> 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.

Note that i'm not sure it makes sense for playground repositories to
be in there - as they're alpha code we're not yet distributing.

As a general matter of policy we don't allow Playground projects to be
released - they have to go through review (and end up in
Extragear/Applications/Plasma/Frameworks) first.
We don't offer CI coverage usually either.

In terms of Extragear, divisions / products is more of a "release
unit" so locking them all together in one item is bound to cause
problems but i'm on the fence as to how to handle these as having one
for each would be a bit overkill I think. We probably need to go
through Extragear at some point and sort the maintained from the
unmaintained...

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

Cheers,
Ben

>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]