[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]