State of Proposal to improving KDE Software Repository Organization?

Mon Jan 18 20:33:08 GMT 2016

On 18 January 2016 at 20:27, Boudewijn Rempt <boud-4ZnIdb/JcHVAfugRpC6u6w at public.gmane.org> wrote:

> On Mon, 18 Jan 2016, Friedrich W. H. Kossebau wrote:
>
> 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"
>>
>
Thanks Friedrich, as always you introduce great amount of structure and
logic to KDE projects :)

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.

> What I'm wondering is, where is this "structure" actually visible? Not in
> 
>
> https://quickgit.kde.org/
>
> or
>
> https://phabricator.kde.org/diffusion/
>
> I see it reflected in the old, to be discarded
>
> https://projects.kde.org/projects
>
> But where else? And what is it actually needed for?
>

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

today I edited it: https://git.reviewboard.kde.org/r/126797 )
Is this visible on the web page? No idea.
e.g. https://build.kde.org/view/Calligra/ 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.

>
>> (("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
>>
>
> It's ghastly -- almost insulting. It's perpetuating the fallacy that
> there are core KDE projects and peripheral projects.
>

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.

>
> * "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)
>>
>
> Horrible as well.
>

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

>
> * 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
>>
>
> 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.
>
> 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.
>>
>
> That again begs the question: where is the "organization" which apparently
> has
> purely technical reasons visible to contributors and users?
>
> (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.
>>
>
To add a perspective, more smaller repos may or may now pop up out of the
OTHERAPPS (calligra.git for now) in order to be properly shared. This comes
with maintenance costs (nobody dreams of a single-C++-class repo). So after
the repo split there are cases of copied code. Look at this as temporary
state - having buildable projects is more important than having no files
duplicated from the day zero.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20160118/1049dbb1/attachment.htm>
-------------- next part --------------
_______________________________________________
calligra-devel mailing list
calligra-devel at kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel