Feel free to propose alternatives. E.g. it would be cool to have the kdb/kreport/kproperty projects moved to a place more like in "framework". Probably not extragear as it's going to be removed (?) according to https://mail.kde.org/pipermail/calligra-devel/2016-January/015829.html?

One thing for sure, these projects no longer belong to playground as stable software depends on them, right?

Uhm, whatever will happen to extragear, we will need to find a place for the libraries currently there. I mean, there will be a set of libraries not part part of Frameworks but marked as "released" (if extragear goes away *as namespace*, playground will do it as well, but repositories will be marked as "released" or "playground" with tags or something similar.

That said: regardless of future moves, do you want to move those libraries under calligra/frameworks because they are released and you don't think that extragear/libs is the proper place?

In D2659#49454, @staniek wrote:

One thing for sure, these projects no longer belong to playground as stable software depends on them, right?

Did they have reviews from the wider community? I don't remember seeing an email in kde-core-devel

From my perspective, we will need a place between Frameworks and the existing scattering between Applications / Extragear for libraries to live as many won't want to commit to the BC promises of Frameworks. That is a matter for another thread though.

In reference to my comment there, what I meant is that "Extragear" won't be a project for repositories to be tagged with on Phabricator. Only things which release a grouping of repositories in one go will need grouping tags (Frameworks, Plasma, Applications all fit this so will have projects to tag their repositories with on Phabricator).

In D2659#49483, @aacid wrote:

In D2659#49454, @staniek wrote:

One thing for sure, these projects no longer belong to playground as stable software depends on them, right?

Did they have reviews from the wider community? I don't remember seeing an email in kde-core-devel

Neither I do remember. These are not core libraries, not a proposal for KF5, just in development and use since 2004, sometimes 2008. Code reviews are practiced.

One note, if staying in playground has no effect for how the tarballs look the upcoming beta releases, priority of these changes is not high.

Release task is T3592, release planned for 19th.

Descriptions are already OK since the project.kde.org times, maybe with exception of the projects/calligra/calligra/metadata.yaml. I can separate the fix for calligra description.

@staniek what's the status of this? I realized we kind of dropped the ball.

Does this still need happening? Is there an agreement in the calligra community on how to proceed?

Kexi frameworks are close to be ready for kdereview - like 90% ready. It's a lot of code so it takes time.

ping?

@aacid 98% :)

This looks interesting, but calligra *shares* more framework like flake. Now Krita has it own copy, is there some plans to split all calligra frameworks?

@anthonyfieroni Turning lib into a framework may need more than splitting. Kexi frameworks show this, and well, it took how many years to deliver KF5? There's not much resources for Calligra development itself...

Now that we have the new CI, with its definition of "products", and the lower importance of the namespace, maybe we can just move those libraries to extragear/libs (aka: libraries with their own release schedule) and be done with that?

Do you mean Kexi frameworks or Calligra libs or both?

Kexi frameworks will have releases, calligra won't (except for already separate KDiagram).

I have pending questions re the new CI. I miss 1. stable builds and 2. Windows builds (Windows support in KDE originates from Kexi exactly). In general I miss flexibility for supporting multiple branches; soon Kexi 4 would be branches and the frameworks (at least KDb and KReport) will be forked to version 4 in parallel. I hope I have not missed something.

I mean "define those 3 libs as libraries with their own release cycle", which in the internal language (but not for the public usage) means extragear/libs. This is not about calligra. What do you mean by "Kexi framework"? The Frameworks version of Kexi or simply these 3 libraries?

The 3 libs form the "Kexi frameworks".

Now I ask, what do you mean by no public usage? We're working for years to enable public usage of these frameworks.

public usage refers to the "extragear" name. We should not use it in official releases. If we can move them (from the namespace point-of-view) to extragear/libs, we should not say this anywhere. They would be simply "programs (libraries, in this case) released on their own release cycle".

Thanks @ltoscano, based on this knowledge then I am OK with moving.

The only think I don't know is: how do I package translations for upcoming 3.0.2. The 'releaseme' tool no longer grabs translations for kexi 3.0 branch. Copying old translations then.