Consider Slowing Down the Release Schedule!

[Boudewijn Rempt]

Just to give an update... We had a rather long discussion yesterday during the meeting. The main concern of that discussion was quality control -- we have been going through quite a few bad regressions, especially with the transform tool, which kind of drowned out other concerns with the release frequency. We also discussed that improvements like this are exactly what Epic has sponsored us for.

So, let's first jot the down the what why of the current situation:

* We discovered that nobody was actually testing the alpha and beta releases. That was, however, before the binary factory made it easy to provide builds for all os'es, and when our community was much smaller.

* The solution was to make much more frequent bugfix releases, like 9 to 12 times a year, so all new code would find its way to the users -- the only way to get really broad testing :-(

* We also wanted to have at least one, preferably two feature releases a year, in spring and autumn. I sort of thought we hadn't had a feature release in 2019, but we actually had 4.2.0 with HDR in May...

* Making a release isn't that much work these days, thanks to the binary factory, though all together, it's still a couple of days work (beta release, beta survey, release, release notes, signing, windows store packaging, steam packaging).

Next, what I took away from our discussion yesterday:

* We still want to have fixes arrive at our users as soon as possible. A counter-argument is that regressions also arrive as soon as possible -- and a counter-counter-argument is that with a slower release cadence, those regressions remain the user's hands for longer.

* Having a host of bug-fix only releases creates the impression that we're only fixing bugs (mostly correct for 2019) and that Krita is a heap of bugs (which is not true, even though focusing on bugs makes us all feel that way). This is bad for our public image.

* We cannot rely on the nightly stable builds (krita next) to allow people to work around regressions in stable releases too much for two reasons: Windows Store and Steam users don't get those fixes, and we would have to deal with too many different builds in bug reports.

* As a tangent, we should do a better job telling people what we're doing. Hellozee wasn't present for the meeting because he was traveling after conf.kde.in, but he's doing a weekly what-happened write-up. It would be better, I think, if that appeared on krita.org and in the news feed.

What we decided on, for now:

* We move to a six releases a year cadence, with a release every two months. This was actually already planned for the first 2020 release, see the release schedule in the meetings document.

* We will have a longer, at least two weeks beta period.

* Everyone who has worked on features or bug fixes for that release, will have to make a list of things to be tested. We will track that in Phabricator for now. 

* In the future, we will give https://kiwitcms.org a chance -- but KDE's sysadmins are too busy right now with the gitlab migration to create a test instance for us right away.

* https://phabricator.kde.org/T12564 -- this is a task where we'll have to define what our top priorities for Krita are, and which functionality is the most important in Krita. (Though I have a hard doing that myself, so please join that task and add your suggestions).

-- 
https://www.krita.org