[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Consider Slowing Down the Release Schedule!
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2020-01-21 8:58:26
Message-ID: 4365512.hQ8lVszByb () boud-thinkpad-t470p
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]