Handling of splitted Calligra repos and API changes
Tomas Mecir
mecirt at gmail.com
Mon Aug 31 12:05:09 BST 2015
2015-08-31 12:15 GMT+02:00 Friedrich W. H. Kossebau <kossebau at kde.org>:
>
> For the start, for now, in current Calligra master I would like to propose
> to
> apply the BIC-day approach.
>
> So a Stage&Flake-concentrated developer only has to pull kdb, kproperty &
> kreport on one day in the week, to always stay with a building master.
>
> Once there is a working alternative, which is understood and has working
> utils, we can switch to that any time.
>
> Yue, Camilla, Leinir, Zagge, Tomas, what is your take on this?
>
Well, only really having time to do Calligra stuff over weekeneds (and none
for the next month or two still) means that for me it makes little
difference whether there is a BIC-day or not, I still need to rebuild every
time. Which in turn means that the best approach for me is that I pull as
little as possible when doing bigger things, only pulling and merging when
I'm ready to push. Suboptimal, sure, but still better than recompiling all
those libs/etc all the time.
With frameworks libs, I can just keep the current stable release around,
only update when the next one comes around, and maintain a reasonable
expectation that things will work still. The libs are currently coupled
much tighter with calligra than frameworks are, but the ideal situation for
me would be having the libs (or more specifically, the libs' public
interfaces) change as little as possible, and be self-contained as much as
possible. This is easy with things like pigment, but probably less so with
others.
(Not sure who proposed removing pigment, by the way, but I think that we
definitely have use for color management in the office part of calligra,
even if may not be as important as krita's needs)
As for other libs, sharing anything that is fairly isolated is great (and I
definitely like the idea of pulling ODF support or formulas out into a lib,
for example), but sharing things that then require workarounds in apps is
less so.
I also think that flake should be as minimal as possible, only providing
the essentials needed for component embedding to work, but that's probably
a different discussion, and/or a pipe dream.
/ Tomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20150831/8a724d9e/attachment.htm>
More information about the calligra-devel
mailing list