Published 27th November, 2017
With all the turmoil the project experienced in 2017 it looked for a while as if we wouldn’t have a face to face meeting this year. But that’s not good for a project working on its fourth major release! We knew we really had to sit together, and finally managed to have a smaller than usual, but very productive, sprint in Deventer, the Netherlands from Thursday 23th to Sunday 26th.
Not having been together since August 2016, we had an agenda stuffed with a enormous backlog of items. And since we’ve been working on new code for a long time ago, our bug tracker was also slowly dying from elephantiasis of the database.
Let’s do the bug tracker first: we managed to close over 120 bugs! Not every bug that gets closed gets closed with a fix: the problem is that most bug reports are actually help requests from users, and many of the rest are duplicates, or requests for features that are irrelevant for Krita. Still, while triaging the list of open and unconfirmed bug reports, we managed to fix more than a dozen real bugs.
Here’s the proof:
Now let’s go to the other topics that were discussed…
We finalized the set of features that we want to complete for 4.0, and came up with a schedule. Originally, we wanted to release 4.0 this year, but that’s completely impossible…
We still want to add:
We are also still facing some problems on some platforms: on Linux, we don’t have a working script to package Python and GStreamer in the appimages, and the way we package G’Mic is wrong. On OSX, we don’t have a working G’Mic at all, and no support for PDF import. We do need help with that!
The current release schedule looks like this:
Right now, the focus is on releasing Krita 4.0, which means that currently no new Krita 3.3.x bug fix releases are planned, even though there are plenty of fixes that can be backported and should be released.
We’ve been approached about supporting HDR screens in Krita, which is different from the existing 10 bits/channel screens that Krita has supported on some systems for a long time. But even though we can get access to the hardware, we don’t have the time to work on it, and the API’s seem to be exclusively Windows-only.
This was a 2017 Google Summer of Code project. We had an almost working implementation, but something changed server-side which means that right now nothing works. It turns out to be pretty hard to figure out what’s up, and that means it’s unlikely Krita 4.0 with have a dialog for download resources from share.krita.org.
Over the summer, we have gained a lot of experience with our Python API, also thanks to our Google Summer of Code student Eliakin. We found some places where the current API needs to be expanded and decided to do just that…
Krita has participated in all editions of Google Summer of Code, and many of the current developers cut their teeth on Krita’s codebase during GSOC. We discussed how we could improve our participation, and how we could attract the kind of students who stay around after the project ends. One problem there is the new rules, which specify that a student can participate only twice. In our experience, it is much better for retention if students can participate during their entire university career.
We also decided to raise the bar a bit. We often see candidates who fulfill the current requirement of three patches with three one-liner patches. We’ll create a set of tasks that have a rating (1 to 3), and only candidates who have reached at least 6 points of completed tasks will be acceptable. We will also test the candidates on their ability to navigate the codebase by asking them to make a diagram of a particular subsystem.
The telemetry Summer of Code project has resulted in working code and a working server, but was not far enough to be mergeable to Krita. We are still interested in learning what we can about the way Krita is actually used, though. The student is interested in doing his bacherlor’s thesis on this subject, too.
Currently, information about contributing to Krita is scattered all over our website, our manual, the KDE community wiki, the source code repository and external websites. Jouni has created an outline for a contributor manual that should be part of our manual website. We’ve even already started on some parts, like the bug tracker howto!