After 2.9.7

[Camilla Boemann]

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