Published 12th August, 2019
Officially, on Friday the 2019 Krita Sprint was over. However, most people stayed until Saturday… It’s been a huge sprint! Almost a complete convention, a meeting of developers and artists.
The sprinters, artists, contributors and artists/contributors, all together.
On Monday, people started arriving. It was pretty great to meet again so many people who hadn’t seen each other for a long time, and to see so many people who hadn’t been to any Krita sprint before. We had rigged a HDR test system in the sprint area, which was, probably for the last time, since it’s getting too small, the 12th-century cellar underneath the Krita maintainer’s house, in the town centre of Deventer. Wolthera was kept busy all week giving an introduction to painting in HDR — she is, after all, the first person in the world to have actually done creative painting in HDR.
There was other hardware to test as well, like the Android tablet with Sharaf Zaman’s Android port of Krita. Sharaf couldn’t come to the sprint; his visum was denied, probably because the Dutch authorities were informed beforehand of the intention of the Indian government to cancel Kashmir’s special status. With a blanket closure of internet, mobile telephony and landline telephony, it was impossible to be in touch with Sharaf. We did some thorough testing, and we hope contact with Sharaf will be restored soon.
Since we still weren’t complete, we postponed the meeting until Thursday, so this day was a day for hacking and discussions. We had many more artists joining us than previously, so the discussions were lively and the meetings were good — but there were more bugs reported than bugs fixed.
On Wednesday, we went on an expedition, to the Openlucht Museum. With twenty-three people attending, it was more efficient to actually rent a bus for the lot of us. The idea about the outing was to make sure people who had never been at a sprint and people who had been at sprints before would mingle and get to know each other. That worked fine!
We had a somewhat disappointing guided tour. I had asked for a solid introduction in the social history of the Netherlands, but the guide still felt he needed to make endless inane and borderline sexist jokes that all fell very flat. Oh well, the buildings were great and the people inside the buildings were giving quite interesting information, with the rosmolen being a high point:
And as you can see, it gave the artists and developer/artists amongst us a chance to do some analog painting (althoug at least one sprint attendant tried to paint with Krita on a Surface tablet, unfortunately cut short by battery problems):
We followed up with dinner at an Indonesian restaurant, and went home tired but satisfied. There was still hacking and painting going on, though, until midnight.
Today we really had the core of our sprint. Some sprints are for coding, but this sprint was for bringing together people and gathering ideas. On Thursday, we discussed the future of Krita in quite a bit of detail.
In 2018/2019 the focus was fully on fixing bugs. There are now two full-time developers working on fixing bugs and improving stability more than this time last year, and both Boudewijn and Dmitry have dedicated all their coding time to fixing bugs as well. Weirdly enough, that doesn’t seems to make much of a dent in our number of open bugs:
One reason is that we manage to introduce too many regressions. That’s partly explained by our new hackers needing to learn the codebase, partly by an enormous increase in our user base (we’re on track to break 2,500,000 downloads a year in 2019), but mostly by our changes not getting enough testing before releasing. So, taking things out of the order we discussed them at the meeting, let’s report on our Bugs and Stability discussion first.
As David Revoy reports, the 4.2 releases don’t feel as stable as the 4.1 releases. As noted above, this is not unexpected since we have two new full-time developers working on Krita, who aren’t that deep in the codebase yet. Another reason we have so much trouble with the 4.2 releases is that we updated to Qt 5.12, which seems to come with many regressions we either have to fix in Qt (and we do submit patches upstream, and those are getting accepted), or work around in Krita itself. On the other hand, we are merging bug fixes into our release branch until the last minute before the release, so those fixes get barely any testing: so the lack of testing isn’t something we can blame on our users, it’s to a large extent our own fault.
Yet Raghukamath and Deevad noted that they both don’t actually test master or the stable branch from day to day anymore because they are too busy actually using Krita, and the same goes for the other artists present. It’s clear that the developers cannot do regression testing, that our extensive set of unittests (although most are more like integration tests, technically) doesn’t catch the regressions — we have to find a better way.
Coincidentally (or not…) Anna (who was not present) had started some time ago a discussion about this on phabricator: T11021: Enhancements to quality assurance). There are many parts to that discussion, but one thing we concluded, based on discussions during the sprint, is that we will try the following:
Slightly related: we also want to do a monthly update article on changes for master, but without the survey mechanism. However, that would make two development updates a month, which might be a bit much to digest, so we’re starting slowly, with the stable release system.
In October we will release a hopefully super-stable Krita 4.3, with a bunch of new features as well, but still focused on stability. Boudewijn is still working on fixing the resource handling system, but that is going really slow, and is being really hard. It’s also hard for the maintainer of the whole project to find time to work on big coding projects, and it’s getting harder, the more management-like tasks there are.
Everyone in the meeting agreed that the text tool still needs much more work, maybe even another rewrite to get rid of the dependency on Qt’s internal rich text editor: the conversion between QTextDocument and SVG is lossy, and gives problems. We were all aware of the missing bits and the problems and bugs, so we didn’t need to discuss this in detail. So one focus is:
So it’s clear that we still need to work on…
Since we had some many artists around whose view we had never before been able to canvass, we decided that digging into workflow issues might be the best thing to do: it would make a good theme for the next fundraiser, too. So:
Some of the workflow issues mentioned already sound like new features, and then there were a number of discussions about what really would be new features:
Anoother thing that was discussed briefly was telemetry (we tried that, the project failed).
Our presence on Twitter, Mastodon, Tumblr, DeviantArt, Reddit is fine. On Facebook, non-official groups are more used than Krita’s own account (which is because Boud is the last maintainer standing, and he cannot stand facebook). Youtube needs improvement, we are absent on Instagram.
Sara Tepes volunteers to handle Krita’s instagram account (which we don’t have). Sara also wants to run “competitions” on Instagram with the prize being having the a number of selected images shown on either Krita’s splash or Krita’s welcome screen.
The splash screen is our main branding location, so we shouldn’t put other images in there other than the holiday jokes.
We could redesign the welcome screen to include an image location; it needs redesign in any case because it’s too drab right now. We wanted it to be not in-your-face, but it’s a bit too much not so now.
Once we have the image location, getting and selecting images can be a problem, as it was for the art book or main release announcements. Sara notes that instagram gives easy tools to select images from a larger set; other platforms are not so good.
In any case, selecting images will be quite a bit of work, and we do need to make sure we’re not playing favorites or forgetting where we come from: free software, open culture.
Conclusion: we are going to try to run the competition on all social networks for which we have a maintainer (instagram, twitter, mastodon, reddit). We can always extend this later to other places. Each maintainer can propose two images + attribution info + links, which will be shown in rotation for a month.
The system for doing this should be ready for the 4.3 release in October.
Note: we have to make a page with a very clear text explaining the rules: we don’t take ownership of the images, the images will be shown in Krita, there will be no licensing requirements for the images, certain kinds of images cannot be used.
Note 2: Scott should ask Ben Cooksley how we can get the welcome screen news widget traffic information on a regular basis.
We have already started improving our presence on YouTube. We feature existing Krita-related channels, and we are working with Ramon to provide interesting videos. We could do more, but let’s give Ramon a chance to build up some momentum first.
Financially, Krita is doing okay. We do get between 2000 and 2700 euros a month in donations: that translates to one full time developer (yes, we’re not getting rich from working on Krita, these are not commercial fees). Windows Store + Steam bring in enough for three to four extra full-time developers. It would be good to become less dependent on the Windows Store, though, since Microsoft is getting more and more aggressive in promoting getting applications from the Windows Store.
Enter the Krita Development Fund. Like in most things, we try to look at what Blender is doing, and then try to find out whether that works for us. Often it does. We already have a notional Development Fund, but it’s basically a monthly paypal subscription or recurring bank transfer. We don’t have any feedback or extras for the subscribers, and the subscribers have no way to manage their subscription, or reach us other than in the usual way. We tried to implement a CiviCRM system for this, but that was way too complex for us to manage.
We need to reboot our Development Fund and migrate existing subscribers to the new fund. A basic list of requirements is:
And no doubt there will be other considerations and requirements. We should check Blender’s dev fund website, of course. We created a Phabricator task to track this, and it’s something we really want help with!
Interestingly, the new gitlab workflow seems to work for everyone. Gitlab’s UI is even less predictable and discoverable than Krita’s, but we didn’t need to discuss anything, people can work with it without much trouble.
Steam wasn’t much of a discussion item either: Windows is doing fine on Steam, our macOS version of Krita still has too many niggles to make it worth-while to put on Steam (or the Apple Store either, even if that were possible, license-wise), and the Linux market share is still too small to make it worth the time investment: still Emmet promised to contact Valve to see how we can get the appimage into Steam. At a first glance, the problem seems to be the version of libc required, which might mean we’ll have to figure out a way to build Qt 5.12 on older versions of Ubuntu or CentOS. But let’s wait and see, first.
Tangentially, we did discuss how to get more people involved in user support, but Agata already has plans towards involving people who already trying to help others in places like Reddit and the forum more recognition. It was late, and the discussion degenerated into hilarity pretty soon — still, this is something to work on, since the core development team just doesn’t have the capacity anymore to help every new Krita user’s teething problems anymore.
To create: a task for rethinking what goes into dockers, and what goes somewhere else.
Friday was the real hacking day. Some people already started leaving, but many people were staying around and started hacking on the issues identified during the meeting, like the action search widget. Bugs were being fixed, regressions identified and blogs posted. And even later on, on Saturday and Sunday, there was still hacking, like on the detached canvas feature.