On 18 January 2016 at 20:27, Boudewijn Rempt <b...@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 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
_______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
