<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-08-31 12:15 GMT+02:00 Friedrich W. H. Kossebau <span dir="ltr"><<a href="mailto:kossebau@kde.org" target="_blank">kossebau@kde.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">
</div></div><span class=""><br>
</span>For the start, for now, in current Calligra master I would like to propose to<br>
apply the BIC-day approach.<br>
<br>
So a Stage&Flake-concentrated developer only has to pull kdb, kproperty &<br>
kreport on one day in the week, to always stay with a building master.<br>
<br>
Once there is a working alternative, which is understood and has working<br>
utils, we can switch to that any time.<br>
<br>
Yue, Camilla, Leinir, Zagge, Tomas, what is your take on this?<br></blockquote></div><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">(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)<br><br></div><div class="gmail_extra">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.<br><br>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.<br><br></div><div class="gmail_extra">/ Tomas<br><br></div></div>