What is Krita up to now?

First disclaimer: I, of course, don’t speak for the whole project, I just write what I personally see and feel. And the blog post contains some technicalities; if you’re not interested in that, just skim over it, you’ll get the feel of it anyway. Or just skip straight to Future .
And btw, I have written most of this post at least two weeks ago, so the beta release that will happen probably this Wednesday, I believe, is just a coincidence.

Past

In October last year we were focused and the direction was clear. Now, a half a year later, the situation is much different.

Last summer our plan was simple: get the resource rewrite done, fix as many bugs as possible, release 4.3.0 with resource rewrite and make a fundraiser for next year of development.

In October we already knew that fundraiser in 2019 is not going to happen and that the resource rewrite needs quite a bit of work as well. We assigned more developers to the resource rewrite task and we had two sprints: one in October, focused on getting those developers (me, Wolthera and Dmitry) engaged in the task, going to BlenderCon and real life meeting with some of Krita’s business partners, and second one in February, this time focused entirely on resource rewrite and describing the resource rewrite design decisions to the last developer (Ivan) who wasn’t there in October.

However as much as we wanted to focus on the resource rewrite, external factors ruled it out again and again. We had quite a lot of issues with building Krita on Windows and Mac, especially Python scripting and notarization on Apple that is now required for the program to be run on a standard user’s Mac. Both of it took several months to rule out (we’re dealing with it since January) and notarization still has some issues. It’s a boring, tedious, frustrating job, which I could taste at the very beginning (with just updating Krita’s dependencies on Windows) around January, but later it was mostly dealt with by Ivan, Dmitry and Boudewijn. Python is particularly tricky: on Windows there are two different Pythons, one (must be installed on the system) is for building Qt, one needs to be built and it provides Python scripting for Krita. Mixing those two up results in the wildest errors.

Another thing we’ve been busy with are regressions, mostly crashes with Colorize Mask, onion skin and animation files and the Transform Tool. Additionally some of the developers took their time off, be it for family reasons, health reasons or any other personal reasons.

In the end, I believe that on the resource rewrite I was the one working the most in the last several months, but even I wasn’t working on it all the time. On the last sprint I started working on bundle manager and resource manager, but after I implemented all functionalities, it turned out that I need a precise plan for the resource manager – I created a mockup, I put it up on krita-artists.org and started working on something else, my pet project of sorts: Wishes Manager.

Present

So, yeah… the resource rewrite isn’t finished yet. Let me write down what every developer is working on.

Dmitry is helping voronwe13 (a very new, but a very promising volunteer) on new types of brush tips and textures, which allows for real-time, quick and easy impasto effects, but he says he’ll come back to bugs soon. I got assigned a task to improve selection tools a bit – those are explained here if anyone is interested: https://forum.kde.org/viewtopic.php?f=288&t=165355#p430735 – I implemented the second one already, but I have some issue that needs to be solved, then I will implement the first one and come back to the resource rewrite (I have two branches that are not on the official repo – one with a brand new Resource Manager, and one with Bundle Manager bundles view fixes to make it more user-friendly, but both are in a very messy state). Boudewijn and Ivan were busy doing builds, Wolthera works on the manual, but says she’ll come back to coding soon as well.

On the positive note, we’ve got two new developers: Emmet and Eoin, both were known to Krita project before as volunteers. Emmet maintains Steam version of Krita for, hmm, not sure how many months already, for sure over a year but was it one year or two? And he always did a great job there. Now Emmet and Eoin are working on animation. They made a list of tasks and they are running through them with a speed that leaves us, senior, long-time Krita developers (says Tiar, working already for a full year !) completely embarrassed. See for yourself: https://phabricator.kde.org/T12769 .

Very recently Boudewijn, seeing that the resource rewrite branch is getting quite stable and we can actually paint on it now (thanks to Dmitry), merged it to master. A few issues later and after the release of 4.2.9, it was decided that branch krita/4.2 will be finished and we’ll release 4.3.0 with everything we had on master before the resource rewrite, and the resource rewrite release will become the grand Krita 5.0. Hellozee, our volunteer and a GSOC student from last year and applicant for this year, is now removing an ancient code that Krita kept as a compatibility feature (so that text and shapes created in older Krita can be open in Krita 4 as well). Right now branch master (you can download a nightly build on Krita’s website under the name Krita Next ) contains the resource rewrite, while branch krita/4.3 (on the website as Krita Plus ) contains the next release, including features like magnetic selections, RGBA (”impasto”) brushes and more.

Future

We’ve got a bit of a problem. Previously, our plan contained the following:

1. get the resource rewrite done,
2. fix as many bugs as possible (decrease the number of bugs),
3. release 4.3.0 with resource rewrite,
4. make a fundraiser for the next year of development.

None of it was achieved, and some of it is already impossible. The resource rewrite still needs a lot of work. Bugs number increases every day. Our extremely optimism-inducing bugs number graph we include in our weekly meetings looks like that:

In spring and summer last year most of us were working solely on bugs, so the number decreased. But then we released 4.2.0, and the bugs number skyrocketed, and it didn’t stopped since. It’s not all regressions, although to be honest, 4.2.0 wasn’t the most stable release ever (since I’m doing user support and I knew all issues preventing people from using one release and another (crashing on startup on Windows, saving issues on Windows, Colorize Mask crashes, animation files crashes…), I feel like version 4.2.9 is the first one I can just tell everyone to use). Considering our promise on the last fundraiser was that we will decrease the bugs number to zero , it looks terrible. It’s not from lack of trying… but all the easy bugs are fixed, now nearly every one of them requires a few days, a week or even more of work. And we have 555 left. And even bug fixes can cause regressions and more bug reports… it’s a Sisyphean work.

On the side note, I was reading the Joel on Software blog: joelonsoftware.com and in the article Top Five Wrong Reasons You Don’t Have Testers ( https://www.joelonsoftware.com/2000/04/30/top-five-wrong-reasons-you-dont-have-testers/ ) he wrote: Unfortunately, neither Netscape, nor any other company on earth, has the manpower to sift through bug reports from 2,000,000 customers and decide what’s really important . I think I’d like to write some polemics to some little parts of this article, but for now – considering Krita has 3 millions of users and counting, I guess it’s not unexpected we cannot fix all of them, if even managing seems impossible to a bystander…

Last autumn we also got a Coverity scan, which means automatic checking for mistakes in the code, and we still have around 900 issues to fix.

Krita 4.3.0 won’t contain resource rewrite, because while we are working on it, the old master branch got so many new features (a lot of them coded up by volunteers, GSOC students etc.) that it’s better to release them earlier, so that users will get those features earlier and the new wave of bug reports will be divided into two smaller ones.

And, of course, the fundraiser is out of question. (It’s a lot of work to prepare one, too). And we still haven’t fulfilled the last fundraiser’s promise, have we. (That’s of course not entirely true. We did work hard. Our work is visible on the graph. I hope it is visible in Krita, too. But still, I’m a bit disappointed).

There is also an issue with testing – both unit tests and beta testing. Every time we touch some part of the code, one needs to make sure that it’s both documented and covered in unit tests. There are sometimes things I’m not sure how to make unit tests of – especially since Krita is really signal-heavy. For beta testing, there is one strategy that is already in place which is releasing a beta version two weeks or, in case of major version like 4.3.0, a month before the release, sometimes with a survey. We also have plans for making a new platform for beta testers so that we can coordinate test cases, testing specific features, regression testing etc. to make sure that all of the components are given enough attention according to their importance or frequency of usage. Participating in beta testing is and probably will be voluntary – we don’t have a single paid tester.

I feel like there is a huge amount of work still left that is invisible to our users (resource rewrite is mostly in the very guts of Krita, bugs often happen only in some circumstances that average user might not see…). And there is still a constant demand to improve of our other unfinished/unpolished areas: animation audio, text tool, shortcuts system, all of it requires a lot of work or thinking. Now that Eoin and Emmet fixed the animation cache, finishing up the Animated Transform Mask (which would allow for tweening, which for me is essential to get done, the task description is here: https://phabricator.kde.org/T11476 ) is possible to be done quite quickly. But that’s just one thing of at least fifteen I can recite at any given time from what I want to be done in Krita.

I feel like we don’t have enough manpower to handle all of this. (It might be because I’m still considerably new in the project – I wasn’t there, so I have no way of knowing if this is the constant state of the project. And I have a bit of a suspicion it is).

Thing is, the bug fixing, stabilizing, writing documentations and unit tests, resource rewrite or any other architectural rewrite – it’s not something we do and we’re done with it. Ok, maybe resource rewrite will be that way, but there will be a new thing to rewrite or rethink, or another huge architectural change, or another optimizing that just needs to be done , but it’s not something we can put on colorful gifs titled See how amazing this new thing is!

Moving forward, Krita has a tough decision to make. What should we focus on? Resource rewrite? New features? Trying to polish up what we have already? We need to make sure those technicalities are sorted out – but we also we need to make sure that our users get their new shiny features. Simultaneously. I believe we need to divide our attention between shiny features and groundwork. Now, the ratio is something to decide upon.

There is this fitting phrase in Polish: ”trying to catch two magpies by their tails”, or maybe ”trying to catch two magpies’ tails at once”. I tried to look up an English phrase, but ”spread oneself too thin”, while having some inherent truth to itself, isn’t that funny and anyway, I ain’t butter . The magpies though, that sounds exactly how I feel what we’re doing at Krita now.

It is, I believe, the best strategy for now, it’s just a tiny bit messy, and I bet I’m not the only person who’s lost. I’m sure we’ll figure it out in the end though.