After 2.9.7

[Tomas Mecir]

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.

/ Tomas


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20150829/3ffba6eb/attachment.htm>