After 2.9.7

Sat Aug 29 22:41:25 BST 2015

On 29 August 2015 at 14:35, Tomas Mecir <mecirt at gmail.com> wrote:
> Heya,
>
> no strong opinions on krita split either way, but while the libs stuff is
> discussed, figured I'd send in the perspective of the
> not-particularly-active Sheets maintainer :D
>
> A problem that I have been running into with Sheets is that the shared libs
> seem to contain more things than may be necessary. Can't really come up with
> specific examples (though they would mostly involve flake/plugins), but
> several times I've found that while fixing this or that bug/oddity, I ended
> up having to crawl through quite a web of inter-dependencies between Sheets
> code, libs code, then back into Sheets, bonus points if one more libs detour
> was made.
>
> That in itself isn't a concern, but when any change to libs could break
> words or krita or whatever, it makes things a little bit tricky, as you can
> imagine. So from the application maintainer perspective, I'd like to see the
> libs as isolated as possible, so that I can essentially treat them as a
> blackbox (same as Qt / KDE frameworks). I don't know how feasible that is,
> as we rely on flake for embeddability, but improvements in this area would
> be quite appreciated, if they are possible.
>

Good that you mention the black box approach, Tomas.

tl;dr having kexi.git fits to the actual needs.

I think we within the Kexi part of Calligra) are happy after isolating
kdb.git, kreport.git and kproperty.git.
It helps to focus. And hacking a 20kLOC repo isn't as scary as hacking
1.5MLOC+ one.

Everyone, please let me look at the libs and apps, where we are now.
There's no forking/splitting just for forking/splitting. Isf something
will happen there are serious reasons.

There are examples of what would be a generally useful component. This
makes a candidate for separate 'lib' repo.
I mentioned some of that during the IRC discussions: filters and
odf-related code look like generally useful. Nobody in Qt world has
that.
If it's also beneficial for Kexi (mail merge/various imports/exports)
to use these bits cleanly without forking - so some work would go into
them from my side. I hope that by the time when they are needed by
apps outside of calligra.git, they won't rot too much. Well why would
they? For their good condition we need the traditional office apps
maintained.

Examples for Sheets: functions (including statistical) are definitely
generally useful for programmers. It's a must have for Kexi. So a repo
for that would be cool, and some work would go there too. A
spreadsheet QWidget is another example but harder to reuse.

Another thing, this time READY: the kdiagram repo - this was not
mentioned I guess but let's call it achievement! Thanks Friedrich.
Another useful component, useful in the way I am trying to show.

We potentially expand the user base to developers.

Let's have releases of these bits this year together with traditional
calligra apps. Have a github clones. Spread the word.

Re the apps, Words/Sheets/Stage -- nobody has so much developed
Qt-based code for ODF editing and viewing. It's not going to change.
We understand that so often 80% of work is fixes and only 20% if the
initial enthusiastic development. Really, I've seen 'commercial' code
does 10% of what calligra does and is many times bigger. We rock in
terms of readability, this is rare!
I heard that from new developers that look at calligra code.

Re: Dependencies. Yes, Krita depending on mysql db is a no-go. Kexi
data processing stuff depending on a colorspace management is a no-go.
They shall be somehow separated. In a single repo it was possible only
because we have cmake and Friedrich's awesome (but custom) productset
logic. Still the calligralibs is a single product, and that's not
natural if some 3rdparty wanted to use a small bit of it without
forking. He'd probably fork and not contribute back (properly).

Re repos: I explained this to Camilla on IRC that physical separate
repos don't make the work necessarily harder.
- you can depend on stable releases of, say, kreport.git, then your
updates are not frequent
- you can hard-depend on some repos if you need, then you need an
equivalent of 'git pull'. Well, a simple script does the work. And
kdesrc-build is another helper for someone that wan't to have a full
build.
Also, I'd give you one case when I bless the separate repos, quite
obvious: if you have 2 independent components and independent feature
branches for both, if they sit in the same repo, you'd merge the
branches into a 3rd one. Then possible merge the master in too. Hmm.
With separate repos you don't do that. No distractions.

We have a good example from the Qt 5 world too.

Summing up the repos topic: I don't vote for splitting everything that
can be splitted. Only those that deserve splitting and will have
dedicated maintainer afterwards. If you split, you offer the
maintainership work, and the repo should be kept self-contained,
generally useful, not just useful for _your_ app but for at least two
apps (more recommended). That's a kind of rule that we have for kf5
libs and calligralibs members.

Re releases: I hope for combined Calligra-branded releases, at least
as many as we can, containing as many stuff as we can have together.
Consistent versioning. This should not suddenly change just because
there are more repos. And if a repo foo.git is not
API/ABI/stability-ready for a stable release, mark it as such, but it
still can be separate, and it would be a release for our
work-in-progress. New release can potentially increase major numbers
quickly. Why? Because by the time of a new
API/ABI/feature-incompatible release someone might start to use
previous version of your lib.

PS (not quite on topic):
Re other apps. Boud explained the case with Karbon.
Let me look at Calligra Plan (disclaimer, I am not a user): I am sure
it's used in real world. I just was happy to hear some of Calligra
developers used it for some projects.
But I see a strategy problem here as a challenge. Sure, development of
Plan/KPlato started in almost pre-Internet times but let's state it --
now even we, KDE folks don't suggest to promote Plan as a PM tool for
our own work here.  Almost everything like that tool is web-based now
-- not just the UI but the workflow is less MS Project-like, that's
what I call web-based here. We never even had proposal of having a
native bug/task tracking app for KDE development, this says something
to me.

> 2015-08-29 10:24 GMT+02:00 Camilla Boemann <cbo at boemann.dk>:
>>
>> As much as I dislike forking I must admit it makes more sense than
>> splitting the libraries.
>>
>> 1) there are conflicting or at list disjoint interests between krita and
>> office. I am not complaining - it's just a fact. Forking will allow
>> specialization - splitting will just produce arguing
>> 2) by splitting it would fall on app maintainers to cleanup - uhm so I
>> would have to spend hours to clean up for krita-needed-changes and vice
>> versa, with no obligation from opposite part to make sure suc changes makes
>> sense or are even possible to adapt to ?
>> 3) the responsibility could possibly right now fall on the committer but
>> let's not kid ourselves - that will change rapidly because it will mean that
>> committers will still have to checkout all repos, making any benefit void.
>> 4) the communities are already rather disjoint - few are present in both
>> irc channels or help out in each other's code
>>
>> On the other hand - the time together has been good or us all but I think
>> the time has come to fork - I have no issue if krita wants to stay in the
>> Calligra suite but even there their main pr and communication have already
>> been split up years ago
>>
>> So I suggest:
>> Krita.git
>> Calligra.git (without author, braindump, karbon, krita and kexi - so just
>> words, stage, sheets and flow, libs , filters and plugins)
>> Kexi.git
>>
>> Kexi are free to depend on Calligra.git, but even for kexi I have my
>> doubts if it wouldn't be better to fork
>>
>> Now I realize this might be the death of the office apps if we have no one
>> left to do website maintainance, releases and general work. I  will do my
>> part but I can't do everything. So if no one is prepared to stay and do
>> releases etc then it still might be better to do the spltting ( but is that
>> a guarantee things will be released or will krita/kexi eventually split up
>> or do their own releases anyway. In which case Calligra will be split and no
>> one to do the even larger release process.
>>
>> If enough people are still interested in the office apps so that we can
>> continue to release then I think forking is the best thing - if not I  can
>> only hope splitting libs will not produce the same fate
>>
>> Best regards
>> Camilla Boemann
>>
>> -----Original Message-----
>> From: calligra-devel [mailto:calligra-devel-bounces at kde.org] On Behalf Of
>> Boudewijn Rempt
>> Sent: 29. august 2015 09:38
>> To: Calligra Suite developers and users mailing list
>> <calligra-devel at kde.org>
>> Subject: Re: After 2.9.7
>>
>> On Sat, 29 Aug 2015, Cyrille Berger wrote:
>>
>> > On Friday 28 August 2015 15:43:12 Boudewijn Rempt wrote:
>> >> Well, we started the discussion with the idea that making separate
>> >> repos for the libraries and applications was going to be useful. That
>> >> rather soon turned into a discussion of the problems we have making
>> >> our libraries fit for purpose for all applications, and that turned
>> >> into "why should, e.g., words and the libraries be in a separate
>> >> repo, it's only a lot of hassle".
>> >>
>> >> And that's where the discussion stopped, so I wrote this mail to
>> >> re-engage the discussion.
>> >
>> > I think the problems raised during that discussion were more:
>> >
>> > 1) How to keep the repositories in sync?
>> > 2) Who will fix breakage in applications?
>> >
>> > I think Friedrich email from yesterday gives a reasonably good
>> > solution for 1).
>> >
>> > As for 2), the biggest problem is for unmaintained applications. But
>> > there, I think we have to take the hard decision of simply killing
>> > those applications, and keep the focus on applications that have
>> > people who care about them. And then, for small changes, it is up to
>> > maintainers to adjust their applications.
>> > Bigger changes should be more coordinated.
>>
>> I am fine with either solution. If splitting off koofdf, kostore and other
>> libraries into "frameworks" means we can continue sharing them, that would
>> be good. If not, I can live with forking the libraries...
>>
>> But before I come up with a proposal and start doing the split-off work,
>> I'd like a real go- ahead :-)
>>
>> Boudewwijn
>> _______________________________________________
>> calligra-devel mailing list
>> calligra-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>> _______________________________________________
>> calligra-devel mailing list
>> calligra-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
>
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>

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