After 2.9.7

Mon Aug 31 09:08:52 BST 2015

Hi, all!

Just my two cents:

1) I'm ok with forking Krita repository. We already depend from quite few
libraries from calligra libs. That is mostly, KoCanvasBase, KoDocumentBase,
flake and pigment.From all four only pigment looks reusable enough for me
to have a separate repo. In our code we hack quite a lot to adapt flake and
document classes for our needs.

2) One more benefit of forking to another repository would be that the size
of the repo would become lower (correct me if I'm wrong). Since "Krita for
Cats" manual is still semi-official way of building Krita on some platforms
this is really crucial for many users. Quite a lot of people still have
GPRS or limited internet, so downloading 700MiB just to try Krita *is* a
barrier. Another problem is translators. Basically, they need to have a
full source tree around to be able to check where the string comes from.

3) And if we decide to fork, I would really love to see a clear plan of
"who-does-what" on each stage, since we have quite a lot of framework
around this repo. Including KDE-CI, Launchpad builds, mails, bugs,
phabricator and etc.

On Sun, Aug 30, 2015 at 12:41 AM, Jaroslaw Staniek <staniek at kde.org> wrote:

> 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
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20150831/4c07d943/attachment.htm>