State of Proposal to improving KDE Software Repository Organization?
staniek at kde.org
Mon Jan 18 20:33:08 UTC 2016
On 18 January 2016 at 20:27, Boudewijn Rempt <boud at valdyas.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
- 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
> I see it reflected in the old, to be discarded
> 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:
> And so on. It's meaningless as it is; it would be better to make that
> 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
> purely technical reasons visible to contributors and users?
> (Being both maintainer of Okteta, which is in "KDE Applications", and
>> 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
>> 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
>> 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
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
: A graphic art and office suite - http://calligra.org
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kimageshop