Proposal to improving KDE Software Repository Organization
mpyne at kde.org
Sun Aug 16 18:51:29 BST 2015
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".
> 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...
> 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 .
> 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
- 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.
- Michael Pyne
Kde-frameworks-devel mailing list
Kde-frameworks-devel at kde.org
More information about the kde-core-devel