DevHeads.net

State of Proposal to improving KDE Software Repository Organization?

Hi,

(calligra-devel, kexi-devel, kimageshop mailinglists only for heads-up,
please remove from reply, discussion only on kde-core-devel should be fine)

4 months ago there was the thread "Proposal to improving KDE Software
Repository Organization" on this mailinglist.
What happened to that plan? Are people preparing its execution?

And would that be a time where some bigger reorganization of the repos is
possible?

Reason that I ask is that due to the split of Calligra into several repos (see
background^) the layout in the repo structure does no longer properly reflect
the project organisation. Right now there are three active repos in the
calligra/ repo substructure:
"calligra" at "calligra/"
"krita" at "calligra/krita"
"kexi" at "calligra/kexi"

(("calligra" at "calligra/" confuses at least kdesrc-build, sent an email to
mpyne about if moving it to "calligra/calligra" should fix it.))

Things that are not properly matching organization:
* Krita starting with 3.* no longer is part of Calligra project
(screws e.g. api.kde.org/bundled-apps-api/calligra-apidocs/ and also
what people think to which project Krita belongs)
* Calligra & Krita are nowhere different to KDevelop, Digikam & Co,
so no reason to be in a complete own toplevel structure,
rather should be in the same sub structure, i.e. "Extragear",
like extragear/calligra/* and extragear/graphics/krita

More, not only Calligra & Krita related:
* "Extragear" is an awful grouping name for apps with individual
release plans, a legacy term that no longer fits most of the apps
in that substructure
* "KDE Applications" is a misleading grouping name for apps with a
central release plan, as if those with individual release plans
are not "KDE" applications (as in, not done in the KDE community)
* a single category per app as needed by the current tree structure layout
of the repos, like "office", "graphics", "utils", is rather awkward,
many apps do not match exactly one or would match multiple categories

So IMHO some update of the repository organisation would be good, to reflect
how things are these days.
Renaming of "Extragear" and "KDE Applications" is surely something which needs
care from promo/marketing/VDG people first to find if that makes sense at all
and what a good solution would be.
(Being both maintainer of Okteta, which is in "KDE Applications", and meta-co-
maintainer of Calligra, which is not, but still done in the very same KDE
community, that current naming seems so wrong to me).

But the actual names and grouping aside, for the pure technical renewing
(which also involves all infrastructure like translation system,
documentation, phabricator, etc), who is currently planning or working on
what?
So does it makes sense to wait some more, or should we assume the current
organization stays for longer, and Calligra & Krita repos should be moved
inside that organization for now?

^Some background about Calligra repo split, as things are slightly
complicated:

KRITA) The "krita" repo was split off, because Krita has finally become a
full project of its own, separate from Calligra. A logical place for the krita
repo in the KDE repo structure would perhaps have been somewhere in extragear,
but at least due to the translators preferring to keep the string catalogs of
Krita in the "calligra" module as before, for less work, the krita repo was
for now put as submodule of "calligra/".

KEXI) Kexi continues to be part of the Calligra project/subcommunity, but the
Kexi developers preferred a small simple repo "kexi" of their own (for build
time and size). So the placement at "calligra/kexi" makes perfect sense.

OTHERAPPS) As the other Calligra apps (Braindump, Karbon, Sheets, Words,
Stage, etc.) are more tightly coupled and the binary interfaces between libs,
plugins & apps can still change every other week, for now no further repo
splitting is planned (to ensure atomic commits on API changes), and they all
stay in the existing "calligra" repo.

Cheers
Friedrich

Comments

Re: State of Proposal to improving KDE Software Repository Organ

By Ben Cooksley at 01/18/2016 - 20:57

On Tue, Jan 19, 2016 at 7:28 AM, Friedrich W. H. Kossebau
< ... at kde dot org> wrote:
Hi,

That plan is tied up in other things taking priority / lack of time / etc.
We'll get there eventually. It is also in part related to the Phabricator move.

Repositories within repositories is a known bad thing to do, the
systems don't handle it properly at all (as it was never an intended
thing you should do). The proper fix is to move the repo to
calligra/calligra (ie. have a "calligra/" top level grouping project).

In the Phabricator world I had envisioned Extragear as no longer existing.

Phabricator will allow multiple "categories" to be tagged to a repository...

Extragear is really an internal structure, not part of marketing so I
think we can go ahead and just kill it...

Like most things in this department, Sysadmin...

Not sure how long things are going to take sorry.
Chances are the existing tree will survive in some form (even if it is
only in the XML file various things use) so you may as well do it now.

Regards,
Ben

Re: State of Proposal to improving KDE Software Repository Organ

By Friedrich W. H.... at 01/20/2016 - 14:00

Am Dienstag, 19. Januar 2016, 13:57:10 schrieb Ben Cooksley:
Okay, so still work in progress. Good.

This move is now requested on <a href="https://phabricator.kde.org/T1337" title="https://phabricator.kde.org/T1337">https://phabricator.kde.org/T1337</a> , the
respective kde-build-metadata change locally prepared.

Okay, sounds good.

Nice, sounds even better.

Seems we all pull on the same string then, glad to see that :)

So in good hands, I leave it there :P Nah, ready to also do some share of work
on this, as I would like this itch scratched as well. Please call me where you
see fit.

Okay.

So to reduce some complexity in the possibly longer living tree then, and to
also resolve this strange exceptional state of Calligra & Krita repos, which I
fear to shape some people's mind, I would like to propose to
* move the toplevel node "calligra/" below "extragear/",
with the repos calligra & kexi ending up at
"extragear/calligra/calligra"
"extragear/calligra/kexi"
(following the example of kdevelop)
* move the krita repo to either
"extragear/graphics/krita" or some new
"extragear/krita/krita", if an own krita section makes sense
So extragear would then contain all non-central repos, and krita would no
longer be mixed into the calligra repo in all places (and thus help people to
get that Krita & Calligra are now separate projects, in all friendship :) ).

While this will mean some adaption work now for all of CI, API, LXR, EBN,
scripty, in the long run it should pay off, for the given motivation.
It would also match plans to reduce the kdesupport/ subtree I think I read
about elsewhere.

What do you think? Ready to do work where I can to get this done.

On the matter of marketing and the term "KDE Applications" I will poke people
separately and later,

Cheers
Friedrich

Re: State of Proposal to improving KDE Software Repository Organ

By Ben Cooksley at 01/21/2016 - 03:36

On Thu, Jan 21, 2016 at 7:00 AM, Friedrich W. H. Kossebau
< ... at kde dot org> wrote:
Okay. People have jumped on using that board a bit earlier than I
anticipated but we can work with that.

In terms of CI the only thing you'll need to adapt for that will be
the build metadata I believe.
API / LXR / EBN might need some cleanup to remove the special cases
for calligra/ but should otherwise be fine.

For scripty you will need to talk with Albert / Luigi.

Regards,
Ben

Re: State of Proposal to improving KDE Software Repository Organ

By =?UTF-8?Q?Nicol... at 01/18/2016 - 21:05

2016-01-18 21:57 GMT-03:00 Ben Cooksley < ... at kde dot org>:
Then the first thing to kill is <a href="https://extragear.kde.org/" title="https://extragear.kde.org/">https://extragear.kde.org/</a> (careful
with potential incoming broken links though).

Re: State of Proposal to improving KDE Software Repository Organ

By Elvis Angelaccio at 01/19/2016 - 03:07

2016-01-19 2:05 GMT+01:00 Nicolás Alvarez <nicolas. ... at gmail dot com>:

Cheers,
Elvis

Re: State of Proposal to improving KDE Software Repository Organ

By Friedrich W. H.... at 01/20/2016 - 12:38

Am Dienstag, 19. Januar 2016, 08:07:11 schrieb Elvis Angelaccio:
Picked that thread up, time to make that a "Done".

Cheers
Friedrich

Re: State of Proposal to improving KDE Software Repository Organ

By Boudewijn Rempt at 01/18/2016 - 15:27

What I'm wondering is, where is this "structure" actually visible? Not in

<a href="https://quickgit.kde.org/" title="https://quickgit.kde.org/">https://quickgit.kde.org/</a>

or

<a href="https://phabricator.kde.org/diffusion/" title="https://phabricator.kde.org/diffusion/">https://phabricator.kde.org/diffusion/</a>

I see it reflected in the old, to be discarded

<a href="https://projects.kde.org/projects" title="https://projects.kde.org/projects">https://projects.kde.org/projects</a>

But where else? And what is it actually needed for?

It's ghastly -- almost insulting. It's perpetuating the fallacy that
there are core KDE projects and peripheral projects.

Horrible as well.

Honestly, the need to group repositories is, to me, so weird that I think
it would be best to adopt the following scheme:

a/amarok
a/...
...
c/calligra
g/gcompris
k/krita

And so on. It's meaningless as it is; it would be better to make that clear,
if grouping is really needed.

That again begs the question: where is the "organization" which apparently has
purely technical reasons visible to contributors and users?

Re: State of Proposal to improving KDE Software Repository Organ

By Albert Astals Cid at 01/24/2016 - 08:00

El Monday 18 January 2016, a les 20:27:16, Boudewijn Rempt va escriure:
You're always welcome to suggest better names.

Cheers,
Albert

Re: State of Proposal to improving KDE Software Repository Organ

By Ben Cooksley at 01/18/2016 - 21:01

On Tue, Jan 19, 2016 at 8:27 AM, Boudewijn Rempt < ... at valdyas dot org> wrote:
Quickgit shows the raw git repository structure, which deliberately
does not include the tree in it.

Eventually we'll have projects for each broader category (Multimedia,
Graphics, etc) and repositories will be tagged for those.
Phabricator will never provide a repository tree though (nor should
it, the existing tree is a hell of a maintenance nightmare).

The build metadata depends on it, and it is used by:

- The CI system
- API / LXR / EBN
- Scripty.
- kdesrc-build

I agree. Which is why i'd like to see the Extragear moniker dropped.
If repositories are part of some broader release unit (like KDE
Applications - even if this does have a better name) then they still
need to visible as belonging to it though I think.

Note that "Frameworks", "KDevelop" and "KDE Telepathy" are all fairly
logical groupings of repositories (and things would be completely
unmanagable in so many ways if we didn't have these).

Regards,
Ben

Re: State of Proposal to improving KDE Software Repository Organ

By Jaroslaw Staniek at 01/18/2016 - 16:33

It's even a bit more interesting that that; there are sub-sub-projects
playground/libs/kdb
playground/libs/kproperty
playground/libs/kreport​

- all historically and by heart ​being part of Calligra. In the future
Calligra _initiative_ can contain repos from any "category", why not?
Everyone can. See below for simple solutions to have that.

​build.kde.org's config (I remember that only because ​

​today I edited it: <a href="https://git.reviewboard.kde.org/r/126797" title="https://git.reviewboard.kde.org/r/126797">https://git.reviewboard.kde.org/r/126797</a> )​
Is this visible on the web page? No idea.
e.g. <a href="https://build.kde.org/view/Calligra/" title="https://build.kde.org/view/Calligra/">https://build.kde.org/view/Calligra/</a> groups some Calligra builds with
direct deps, that's all.

I know chiliproject.org that's used for projects.kde.org would better be
not patched. I hope this can be solved somehow and we can model our KDE
structures by our tools, not the other way round.

​Trees are dead. ​

I'd suggest a flat structure:
- relations between apps is a graph not a tree anymore (Kexi can be both in
office /productivity category as well as software development like KDevelop)
- it's 2016, people search, not browse

Or if categorization is needed, on top of the flat structure, tags are the
real means for that that people understand

There are app description formats: .lsm, .appdata.xml... I use them for
Kexi. Some others too. .lsm supports keywords.

I think semantic tags would be best (or do we use them already?).
A repo can be in a subproject and also belong to a number of categories.

Yes, it's a surprise even to KDE people. Here, Calligra and KDevelop, to
name just them, are not KDE Apps to normal people.