Re: kdiagram in calligra project component?

[Friedrich W. H. Kossebau]

Hi Jarosław,

Am Montag, 5. September 2016, 01:03:32 CEST schrieb Jaroslaw Staniek:
> Hi,
> Background: The kde:sysadmin/repo-metadata git repo now replaces the
> project.kde.org stuff.
> I am moving kdb, kreport and kproperty repo metadata to projects/calligra
> from playground/libs as I see them more fit to the new location and they
> are, well, developed within our master project Calligra anyway, regardless
> of repo fragmentation.
> 
> That's not my play, the kde:releaseme tool which I'd be trying to use for
> preparing releases depends on the projects metadata so it's good to have
> the metadata as correct as possible.
> 
> Now, that's mostly a question to Friedrich:
> 
> There is projects/extragear/graphics/kdiagram. It describes "Powerful
> libraries (KChart, KGantt) for creating business diagrams". Do you think
> that kdiagram better fits to calligra/ and not so much to graphics/?
> ​KChart clearly implements office-oriented objects: data charts and Gantt
> charts.

For one, those paths in the repo hierachy are just legacy and long-term will 
be dropped, for a flat list of repos.

Then, that description is copied unchanged from marketing-buzzword loaded 
origin :)

I had put kdiagram into projects/extragear/graphics after discussion as 
diagrams can be used for lots of things. There is a (business) world outside 
offices :)
Current users known to me of either KChart or KGantt are Massif-Visualizer, 
something in KDEPIM, KMyMoney, Plan, a Calligra shape plugin and a KReport 
plugin.
So KDiagram is a project shared by many KDE projects, nothing Calligra-centric 
there. So I do not see a reason to move this.

More, as long as that legacy adressing hierarchy of repos exists, I would 
rather recommend to move non-Calligra-only stuff like KDb, KReport & KProperty 
somewhere into the generic extragear namespace, as those libs target 
developers, unlike the "apps" which make up what currently is known as 
Calligra and what is about end user products. By being in the generic 
extragear namespace this might help stressing the libs general usability 
outside of the existing set of Calligra apps.

My 2 cents on that :)
Friedrich

Re: kdiagram in calligra project component?

[Jaroslaw Staniek]

On 5 September 2016 at 01:03, Jaroslaw Staniek  wrote:

> Hi,
> Background: The kde:sysadmin/repo-metadata git repo now replaces the
> project.kde.org stuff.
> I am moving kdb, kreport and kproperty repo metadata to
> ​​
> projects/calligra from playground/libs
>

​Actually I invented ​projects/calligra/frameworks even, why not? It more
nicely groups by purpose. So I propose to keep kdiagram there.



> as I see them more fit to the new location and they are, well, developed
> within our master project Calligra anyway, regardless of repo fragmentation.
>
> That's not my play, the kde:releaseme tool which I'd be trying to use for
> preparing releases depends on the projects metadata so it's good to have
> the metadata as correct as possible.
>
> Now, that's mostly a question to Friedrich:
>
> There is projects/extragear/graphics/kdiagram. It describes "Powerful
> libraries (KChart, KGantt) for creating business diagrams". Do you think
> that kdiagram better fits to calligra/ and not so much to graphics/?
> ​KChart clearly implements office-oriented objects: data charts and Gantt
> charts.
>
> --
> 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
>



-- 
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

kdiagram in calligra project component?

[Jaroslaw Staniek]

Hi,
Background: The kde:sysadmin/repo-metadata git repo now replaces the
project.kde.org stuff.
I am moving kdb, kreport and kproperty repo metadata to projects/calligra
from playground/libs as I see them more fit to the new location and they
are, well, developed within our master project Calligra anyway, regardless
of repo fragmentation.

That's not my play, the kde:releaseme tool which I'd be trying to use for
preparing releases depends on the projects metadata so it's good to have
the metadata as correct as possible.

Now, that's mostly a question to Friedrich:

There is projects/extragear/graphics/kdiagram. It describes "Powerful
libraries (KChart, KGantt) for creating business diagrams". Do you think
that kdiagram better fits to calligra/ and not so much to graphics/?
​KChart clearly implements office-oriented objects: data charts and Gantt
charts.

-- 
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

Re: 3.0 Beta releases, compatibility

[Jaroslaw Staniek]

On 4 September 2016 at 17:28, Adam Pigg  wrote:

> I wonder how we can utilise one of the new container distribution formats
> such as
> ​​
> flatpak or snap for distributing betas.  Probably need to do some
> research, would be handy to not rely on distros for pushing out betas, or
> have users building from source.
>

​Taking KDb as example here. KDb is and will be so actively following needs
of Kexi that IMHO it can't be realistically following a "cathedral"
approach to library development in the same time.​
So I imagine stable KDb is 3 and _stable_ Kexi quickly switched to using
KDb 4 beta. "beta" here would rather mean "devel, not for 3rd-party
developers", not "unsable". That means any distribution channel that want
to offer fresh stable Kexi >=3 would have to also package fresh "devel" KDb
releases (probably in addition to "API/ABI stable" KDb releases).

Flatpaks or snap​s would let us distribute with more control in hand (if we
have workforce for that!) but I would say distros do their great job.
​I don't see problems distros releasing beta​s/devel versions. As it's the
case with GIMP which has versions stable X*2 and devel X*2+1.
Also where coinstallable versions are expected by users it's widely
supported (Qt, gcc...).


>
> On Sun, 4 Sep 2016 at 09:06 Dag  wrote:
>
>> Can't give you much advice on releases ;)
>> but +1 for stable releases, so we can avoid the odd regression we've
>> seen in the past.
>> KReport / KProperty is used in Plan so would be nice to have any planned
>> API/ABI changes in before release.
>>
>> Cheers, Dag
>>
>> Jaroslaw Staniek skrev den 2016-08-31 10:45:
>> > Hello,
>> > KDE Akademy[1] is starting so I thought it might be a good point to
>> > push the Beta release button for Kexi and related frameworks:
>> >
>> > KDb
>> > KProperty
>> > KReport (depends on KProperty)
>> >
>> > tl;dr:
>> > - we need source distribution of Kexi and the 3 frameworks to get more
>> > users and contributors
>> > - we need to find a way for the frameworks to serve both for Kexi
>> > needs and general user
>> > - when: release process takes about two weeks, let's add extra week
>> > for a bootstrap of this process
>> >
>> > Details.
>> >
>> > As some of us are aware there are 4 repositories in the Kexi family.
>> > We are no longer "outsourcing" the hard release work to general
>> > calligra, so there's specific work to do. At first it takes some more
>> > effort I think. I'll be looking at scripts such from releaseme.git or
>> > kde-dev-scripts.git.
>> > Advices are welcome here (Boudewijn has offered useful advice already
>> > based on the experience with Krita releases).
>> >
>> > Despite extra work, there are advantages of the separate releases,
>> > more control and possibility of finer-grained releases, not a "release
>> > all or nothing" scheme. Please note this is about the first level of
>> > releases - source code and message translation files. Binaries would
>> > appear thanks to distributors and separate work for Windows.
>> >
>> > The three frameworks have various level of maturity, based on
>> > attention; I'd say the most prepared is KDb, then KProperty, then
>> > KReport. This especially apply to API and ABI guarantees (e.g. see
>> > [2])
>> >
>> >
>> > == How to version ==
>> >
>> > And here's a challenge: at the moment the main consumer of the
>> > frameworks is Kexi. Later it shouldn't be like that, otherwise we
>> > could release a bundled source code based on all 4 repositories.
>> > There's some consumption of KReport and KProperty in the Calligra Plan
>> > app. that's it. It may be that someone plays or even uses git versions
>> > of the code but that was not noticed.
>> >
>> > So since Kexi is the major consumer, current development priorities
>> > for the frameworks are rather Kexi-specific and sometimes it's hard to
>> > keep (or justify fighting for) backward compatibility. A recent
>> > example is an (August) merge of the Kexi's migration API that formed a
>> > lower-level database access APIs for KDb. It's already in master
>> > branch. Fortunately such moves become more rare over time.
>> >
>> > So how to organize development of the frameworks: not blocking
>> > development of features or fixes important for Kexi and staying
>> > (binary) backward compatible? I thought of one approach:
>> >
>> > - Version 3.x of the frameworks becomes binary compatible on first
>> > stable release
>> >
>> > - Version 4.x of the frameworks come into life as soon as needed by
>> > Kexi and incompatible changes happen there, the version would carry
>> > the "Beta" stamp for a long time to emphasize that there's no
>> > compatibility guarantee
>> >
>> > - Kexi 3.0 gets released as depending on 3.x initially and would
>> > switch to 4.x when a need for incompatible changes in framework
>> > appears
>> >
>> > - Co-installability of 3.x and 4.x is assured, 4.x will never be an
>> > upgrade for 3.x (a bit similar to situation with libPNG 12, 14, 16)

Re: 3.0 Beta releases, compatibility

[Jaroslaw Staniek]

On 4 September 2016 at 10:06, Dag  wrote:

> Can't give you much advice on releases ;)
> but +1 for stable releases, so we can avoid the odd regression we've seen
> in the past.
> KReport / KProperty is used in Plan so would be nice to have any planned
> API/ABI changes in before release.
>
>
OK, Dag. One advice. You can depend on strict version like ​3.0.0 or if you
ever need specific behaviour that's since 3.x.y, x>0,y>0, you can update
the dependency too. If we perform API/ABI changes that would be >= 4.0.0
version so if you still stay with 3.x.y dependency in Calligra Plan, you
are safe (as long as packagers don't treat version 4 as upgrade/replacement
for 3 - that's a major thing to check, like with libPNG).

Small update. KDb in master already has co-installability enabled. Its lib
is called libKDb3.so. Major commit is 6c423feac9ca124 if someone wants to
get the idea.
Interesting: users don't need to perform _any_ adjustments after such
changes, the cmake's config scripts transparently find proper version, so
you still refer to the lib by name, as "KDb". In Kexi master it's now:

find_package(KDb 2.96.7 REQUIRED COMPONENTS )

I'd imagine the same would be supported for the other 2 frameworks and
maybe even Kexi internal libs.

Let's hear if there are any remarks from packagers.

PS: co-installability means no two files from two incompatible
installations are the same so packages can't be in conflict (unless
packagers want to set them as such, which we would like to discourage).


Cheers, Dag
>
>
> Jaroslaw Staniek skrev den 2016-08-31 10:45:
>
>> Hello,
>> KDE Akademy[1] is starting so I thought it might be a good point to
>> push the Beta release button for Kexi and related frameworks:
>>
>> KDb
>> KProperty
>> KReport (depends on KProperty)
>>
>> tl;dr:
>> - we need source distribution of Kexi and the 3 frameworks to get more
>> users and contributors
>> - we need to find a way for the frameworks to serve both for Kexi
>> needs and general user
>> - when: release process takes about two weeks, let's add extra week
>> for a bootstrap of this process
>>
>> Details.
>>
>> As some of us are aware there are 4 repositories in the Kexi family.
>> We are no longer "outsourcing" the hard release work to general
>> calligra, so there's specific work to do. At first it takes some more
>> effort I think. I'll be looking at scripts such from releaseme.git or
>> kde-dev-scripts.git.
>> Advices are welcome here (Boudewijn has offered useful advice already
>> based on the experience with Krita releases).
>>
>> Despite extra work, there are advantages of the separate releases,
>> more control and possibility of finer-grained releases, not a "release
>> all or nothing" scheme. Please note this is about the first level of
>> releases - source code and message translation files. Binaries would
>> appear thanks to distributors and separate work for Windows.
>>
>> The three frameworks have various level of maturity, based on
>> attention; I'd say the most prepared is KDb, then KProperty, then
>> KReport. This especially apply to API and ABI guarantees (e.g. see
>> [2])
>>
>>
>> == How to version ==
>>
>> And here's a challenge: at the moment the main consumer of the
>> frameworks is Kexi. Later it shouldn't be like that, otherwise we
>> could release a bundled source code based on all 4 repositories.
>> There's some consumption of KReport and KProperty in the Calligra Plan
>> app. that's it. It may be that someone plays or even uses git versions
>> of the code but that was not noticed.
>>
>> So since Kexi is the major consumer, current development priorities
>> for the frameworks are rather Kexi-specific and sometimes it's hard to
>> keep (or justify fighting for) backward compatibility. A recent
>> example is an (August) merge of the Kexi's migration API that formed a
>> lower-level database access APIs for KDb. It's already in master
>> branch. Fortunately such moves become more rare over time.
>>
>> So how to organize development of the frameworks: not blocking
>> development of features or fixes important for Kexi and staying
>> (binary) backward compatible? I thought of one approach:
>>
>> - Version 3.x of the frameworks becomes binary compatible on first
>> stable release
>>
>> - Version 4.x of the frameworks come into life as soon as needed by
>> Kexi and incompatible changes happen there, the version would carry
>> the "Beta" stamp for a long time to emphasize that there's no
>> compatibility guarantee
>>
>> - Kexi 3.0 gets released as depending on 3.x initially and would
>> switch to 4.x when a need for incompatible changes in framework
>> appears
>>
>> - Co-installability of 3.x and 4.x is assured, 4.x will never be an
>> upgrade for 3.x (a bit similar to situation with libPNG 12, 14, 16)
>>
>> This way we have any chance to see users of the frameworks distributed
>> and used.
>>
>>
>> == Q & A ==
>> Q: Why not push the frameworks to the KDE Frameworks 5 family?
>> A: Maybe one day but 

Re: 3.0 Beta releases, compatibility

[Adam Pigg]

I wonder how we can utilise one of the new container distribution formats
such as flatpak or snap for distributing betas.  Probably need to do some
research, would be handy to not rely on distros for pushing out betas, or
have users building from source.

On Sun, 4 Sep 2016 at 09:06 Dag  wrote:

> Can't give you much advice on releases ;)
> but +1 for stable releases, so we can avoid the odd regression we've
> seen in the past.
> KReport / KProperty is used in Plan so would be nice to have any planned
> API/ABI changes in before release.
>
> Cheers, Dag
>
> Jaroslaw Staniek skrev den 2016-08-31 10:45:
> > Hello,
> > KDE Akademy[1] is starting so I thought it might be a good point to
> > push the Beta release button for Kexi and related frameworks:
> >
> > KDb
> > KProperty
> > KReport (depends on KProperty)
> >
> > tl;dr:
> > - we need source distribution of Kexi and the 3 frameworks to get more
> > users and contributors
> > - we need to find a way for the frameworks to serve both for Kexi
> > needs and general user
> > - when: release process takes about two weeks, let's add extra week
> > for a bootstrap of this process
> >
> > Details.
> >
> > As some of us are aware there are 4 repositories in the Kexi family.
> > We are no longer "outsourcing" the hard release work to general
> > calligra, so there's specific work to do. At first it takes some more
> > effort I think. I'll be looking at scripts such from releaseme.git or
> > kde-dev-scripts.git.
> > Advices are welcome here (Boudewijn has offered useful advice already
> > based on the experience with Krita releases).
> >
> > Despite extra work, there are advantages of the separate releases,
> > more control and possibility of finer-grained releases, not a "release
> > all or nothing" scheme. Please note this is about the first level of
> > releases - source code and message translation files. Binaries would
> > appear thanks to distributors and separate work for Windows.
> >
> > The three frameworks have various level of maturity, based on
> > attention; I'd say the most prepared is KDb, then KProperty, then
> > KReport. This especially apply to API and ABI guarantees (e.g. see
> > [2])
> >
> >
> > == How to version ==
> >
> > And here's a challenge: at the moment the main consumer of the
> > frameworks is Kexi. Later it shouldn't be like that, otherwise we
> > could release a bundled source code based on all 4 repositories.
> > There's some consumption of KReport and KProperty in the Calligra Plan
> > app. that's it. It may be that someone plays or even uses git versions
> > of the code but that was not noticed.
> >
> > So since Kexi is the major consumer, current development priorities
> > for the frameworks are rather Kexi-specific and sometimes it's hard to
> > keep (or justify fighting for) backward compatibility. A recent
> > example is an (August) merge of the Kexi's migration API that formed a
> > lower-level database access APIs for KDb. It's already in master
> > branch. Fortunately such moves become more rare over time.
> >
> > So how to organize development of the frameworks: not blocking
> > development of features or fixes important for Kexi and staying
> > (binary) backward compatible? I thought of one approach:
> >
> > - Version 3.x of the frameworks becomes binary compatible on first
> > stable release
> >
> > - Version 4.x of the frameworks come into life as soon as needed by
> > Kexi and incompatible changes happen there, the version would carry
> > the "Beta" stamp for a long time to emphasize that there's no
> > compatibility guarantee
> >
> > - Kexi 3.0 gets released as depending on 3.x initially and would
> > switch to 4.x when a need for incompatible changes in framework
> > appears
> >
> > - Co-installability of 3.x and 4.x is assured, 4.x will never be an
> > upgrade for 3.x (a bit similar to situation with libPNG 12, 14, 16)
> >
> > This way we have any chance to see users of the frameworks distributed
> > and used.
> >
> >
> > == Q & A ==
> > Q: Why not push the frameworks to the KDE Frameworks 5 family?
> > A: Maybe one day but now it's too early and the workforce is too
> > limited.
> >
> > [1] https://akademy.kde.org (I am just present there in spirit...)
> > [2]
> >
> https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
>

Re: 3.0 Beta releases, compatibility

[Dag]

Can't give you much advice on releases ;)
but +1 for stable releases, so we can avoid the odd regression we've 
seen in the past.
KReport / KProperty is used in Plan so would be nice to have any planned 
API/ABI changes in before release.


Cheers, Dag

Jaroslaw Staniek skrev den 2016-08-31 10:45:

Hello,
KDE Akademy[1] is starting so I thought it might be a good point to
push the Beta release button for Kexi and related frameworks:

KDb
KProperty
KReport (depends on KProperty)

tl;dr:
- we need source distribution of Kexi and the 3 frameworks to get more
users and contributors
- we need to find a way for the frameworks to serve both for Kexi
needs and general user
- when: release process takes about two weeks, let's add extra week
for a bootstrap of this process

Details.

As some of us are aware there are 4 repositories in the Kexi family.
We are no longer "outsourcing" the hard release work to general
calligra, so there's specific work to do. At first it takes some more
effort I think. I'll be looking at scripts such from releaseme.git or
kde-dev-scripts.git.
Advices are welcome here (Boudewijn has offered useful advice already
based on the experience with Krita releases).

Despite extra work, there are advantages of the separate releases,
more control and possibility of finer-grained releases, not a "release
all or nothing" scheme. Please note this is about the first level of
releases - source code and message translation files. Binaries would
appear thanks to distributors and separate work for Windows.

The three frameworks have various level of maturity, based on
attention; I'd say the most prepared is KDb, then KProperty, then
KReport. This especially apply to API and ABI guarantees (e.g. see
[2])


== How to version ==

And here's a challenge: at the moment the main consumer of the
frameworks is Kexi. Later it shouldn't be like that, otherwise we
could release a bundled source code based on all 4 repositories.
There's some consumption of KReport and KProperty in the Calligra Plan
app. that's it. It may be that someone plays or even uses git versions
of the code but that was not noticed.

So since Kexi is the major consumer, current development priorities
for the frameworks are rather Kexi-specific and sometimes it's hard to
keep (or justify fighting for) backward compatibility. A recent
example is an (August) merge of the Kexi's migration API that formed a
lower-level database access APIs for KDb. It's already in master
branch. Fortunately such moves become more rare over time.

So how to organize development of the frameworks: not blocking
development of features or fixes important for Kexi and staying
(binary) backward compatible? I thought of one approach:

- Version 3.x of the frameworks becomes binary compatible on first
stable release

- Version 4.x of the frameworks come into life as soon as needed by
Kexi and incompatible changes happen there, the version would carry
the "Beta" stamp for a long time to emphasize that there's no
compatibility guarantee

- Kexi 3.0 gets released as depending on 3.x initially and would
switch to 4.x when a need for incompatible changes in framework
appears

- Co-installability of 3.x and 4.x is assured, 4.x will never be an
upgrade for 3.x (a bit similar to situation with libPNG 12, 14, 16)

This way we have any chance to see users of the frameworks distributed 
and used.



== Q & A ==
Q: Why not push the frameworks to the KDE Frameworks 5 family?
A: Maybe one day but now it's too early and the workforce is too 
limited.


[1] https://akademy.kde.org (I am just present there in spirit...)
[2] 
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B