[prev in list] [next in list] [prev in thread] [next in thread]
List: calligra-devel
Subject: Re: Handling of splitted Calligra repos and API changes
From: Tomas Mecir <mecirt () gmail ! com>
Date: 2015-08-31 11:05:09
Message-ID: CAAREnaMZSZuw6Su5sgsXBvdFWqN2oSPugVfn0JrRuvxNykJmEg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
2015-08-31 12:15 GMT+02:00 Friedrich W. H. Kossebau <kossebau@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
[Attachment #5 (text/html)]
<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>
[Attachment #6 (text/plain)]
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic