On 29 August 2015 at 14:35, Tomas Mecir <mec...@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 <c...@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-boun...@kde.org] On Behalf Of >> Boudewijn Rempt >> Sent: 29. august 2015 09:38 >> To: Calligra Suite developers and users mailing list >> <calligra-devel@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@kde.org >> https://mail.kde.org/mailman/listinfo/calligra-devel >> >> _______________________________________________ >> calligra-devel mailing list >> calligra-devel@kde.org >> https://mail.kde.org/mailman/listinfo/calligra-devel > > > > _______________________________________________ > calligra-devel mailing list > calligra-devel@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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
