Proposal to improving KDE Software Repository Organization

[Michael Pyne]

On Sun, August 16, 2015 17:48:59 John Layt wrote:
> 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 !]

Just to be clear I agree with David that "product" would better match the 
intent of my proposal than "division"; I've spent the past year or so not 
being very satisfied with "division".

> 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...
> 
snip
> 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.

I think this is probably a good conversation to have as well but I do want to 
re-emphasize that the proposal David is referring to relates to how we build 
KDE software, and how we organize to build that software easily.

This involves grappling with at least a couple of things:

- What underlying source repositories make up a given "major product" that we 
ship? (e.g. what comprised Plasma 5? what makes up KF5?). We have to care at 
least about this level of granularity since each of these may have their own 
release cycles.

- For each of those repositories, what is the appropriate branch to build 
from, for a given development branch (e.g. "stable" or "dev")? One of the 
weaknesses of the current "branch-group" scheme is that we list all KDE 
repositories *first* and only then try to map to a branch... but not every 
repository necessarily belongs with every "major product".

But beyond that we already really don't care about extragear/, playground/, 
etc., at least as far as build infrastructure goes. The reason we'd split 
playground or Extragear in the new scheme would be because they operate on 
different release schedules from Plasma, Applications or KF5 (and therefore 
probably have different ideas of 'Release', 'Dev', 'Stable', etc.). For 
playground in particular it would also give us a way to lower the priority for 
those from a CI perspective. But we don't have to make that part of our 
marketing efforts and I'm not aware that we do even today.

> 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.

Well, having a "project hierarchy" is also a slightly different question. 
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).

If we got rid of this it would take away the ability to easily refer 
collectively to related modules though, and I don't think we'd want to 
reimplement that with the high-level "Project" scheme being talked about.

Regards,
 - Michael Pyne
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel at kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel