Proposal to improving KDE Software Repository Organization

[John Layt]

On 16 August 2015 at 11:14, David Faure <faure at kde.org> wrote:

> (*) I keep finding the "division" term a bit obscure, and I wonder if this shouldn't be
> called "product" instead. I.e. matching how we release things. Nowadays we
> basically have 4 products (frameworks, plasma, applications, extragear?),
> previously we had 2 (KDE SC 4, extragear). If this is what you had in mind
> with divisions, then I suggest to call it product for clarity.
> The reason why I think it's the same concept is that the one reason to have
> different tracks is exactly because of different release schedules (e.g. plasma
> could be tested against KF5/Stable (last release) and KF5/Devel (more recent code))

[Rambling naming bikeshed alert !]

TLDR:

We have a Marketing View and we have a Technical Build View and I
think they are different enough to have different names and
structures. How about we call 'division' something like 'build-group'
or 'build-unit' instead? And while we're busy regrouping and renaming
things, lets get rid of the application Modules...

Longer:

I like Product too, which is why I'm using it in the new TechBase KF5
Getting Started docs I started writing today [1] and especially [2],
but I don't see it as being the same thing as 'division' here, and I
think it exposes again a problem in our organisation and naming of
Applications.

My marketing-oriented view is we are organised as 3 Products:
* KDE Frameworks
* KDE Plasma
* KDE Applications

(We could add other products like 'KDE Infrastructure' and KDE
Servers', but they're mostly internal).

Within KDE Applications we then have a confusing mixture of Modules,
Projects and standalone Applications with different porting status and
release cycles:
* Edu Module
* Games Module
* PIM Module
* Playground Module
* Review Module
* Extragear Module
* Calligra Suite
* GCompris
* etc...

Now, some may argue that some of those are actually Products in their
own right, e.g. Calligra and Extragear and GCompris, but they are
Applications developed by the KDE Community within the KDE
Infrastructure and adhering to the KDE Manifesto, they are all by
definition KDE Applications, just with different development status or
release cycles.

'division' appears slightly different to me, it is about grouping
things into standalone build dependency units, so Calligra and
GCompris do appear to belong at that level. OTOH, do we really want
every repo in Extragear or Playground to have their own top-level
'division' just because they have different release cycles or
different porting status or different version dependencies? Even the
official KDE SC4 modules all have different porting status and thus
build dependencies and thus conceivably different 'divisions'. That
would just be too messy. I think how they get grouped into 'divisions'
is always going to be different than the marketing Products and
Modules. Alternative names that spring to mind are 'build-unit' or
'build-group'.

Personally I think the whole
Playground/Review/Applications/Extragear/Unmaintained module level
split needs to go away and all Applications be considered equal, just
with a different release status metadata tag based on the official
lifecycle [3]. It's just reflecting the reality of the git-based split
up of modules, different release cycles, death of a number of our
sub-communities, and a more-focussed view on what makes up the
workspace/applications split and their different release cycles.

So, a proposal: we drop modules and extragear and playground and
unmaintained altogether for organising our repos and paths and build
process and instead just have Applications with a 'release-status' tag
marking where they are in our official KDE Application Lifecycle [3].
A second 'release-cycle' tag could identify those that are to be
included in the regular KDE Applications release cycle.

We can still sort-of keep module, but now it's more a category tag, so
all edu apps live under the path apps/edu/*. This could also remove
some hassle when apps move around, their place in the namespace
hierarchy and path doesn't change, just their release status tag.

John.

[1] https://techbase.kde.org/KF5/Getting_Started
[2] https://techbase.kde.org/KF5/Getting_Started/Source_Code
[3] https://techbase.kde.org/Policies/Application_Lifecycle