After 2.9.7

[Boudewijn Rempt]

On Mon, 31 Aug 2015, Dmitry Kazakov wrote:

> 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.

The repo size is one reason I'm actually considering to drop all
history. Create a fresh new repo with cleaned-up code only and start
again from commit 0. I know we check history a lot, but that history is
the history of Krita up to Krita 2.9.x, which is in the calligra repo.

> 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.

Yes. I guess that would mostly be me. Mailing list and bugzilla are
repo-independent. If we create a new repo, that goes through sysadmin and
that incudes settig up ci, phabricator, reviewboard (well, I'd like to
drop that), translations, release system. Launchpad would be your task,
I'd say.

One big remaining problem is the animation/lod branch. Unless we say,
heck, 3.0 isn't stable anyway, let's merge that to master and work from
there, it's going to be tricky.


But I'll try to make a full list.

Boudewijn