Ok, so happily I actually see quite a bit of agreement here, regardless
of what else we do.
1. Fibonacci bugfix releases are good, and we could benefit from having
Gear adopt these.
2. Severing implicit dependencies is a good idea. Shared libraries in
Gear are especially problematic and could benefit from being moved to
Frameworks.
3. Fast frameworks releases in some capacity are a benefit and we don't
want to lose this.
All in agreement? If so, that would be amazing.
---
Now, let's say we make Gear use Plasma's current release schedule by
syncing up the feature releases and adopting the Fibonacci bugfix
releases. If we don't end up changing Plasma's own release schedule then
we already make our promo store more coherent by letting the marketing
team do three big glossy announcements of user-facing products a year,
rather than being stretched thin for 6. Even if we make Plasma go down
to 2 releases a year, then we have two synced Gear+Plasma
"mega-releases" and 2 independent Gear releases--down from 6 to 4. Both
of these options would improve the promo story IMO.
---
Moving on, the biggest points of contention I see revolve around
Frameworks. Personally I want to push back a bit on the idea of
developing an app against released frameworks. This is only realistic if
you use a rolling release distro and are okay with waiting a month to
use the new Frameworks code. For users looking to contribute with common
discrete-release distros, it is not at all realistic as many Frameworks
consumers require versions newer than what those users have on their
system, so they have to build some Frameworks anyway (note: not all of
them; kdesrc-build/kde-builder are smart enough not to do unnecessary
work). The older the distro's packages, the more likely this is to be.
Furthermore, because Frameworks has time-based releases and no beta
releases, in practice the QA is provided by developers living on master.
If KDE developers deliberately avoid this, they're not participating in
QA. There are of course other ways to improve Frameworks' QA as well,
but continuing to encourage KDE developers to use distro-packaged
Frameworks goes against the larger goal: we can't QA software versions
we're not using.
While 12 releases a year of Frameworks feels fast, it's actually not.
Gear also has 12 releases a year: 3 feature releases and 9 bugfix
releases. And Plasma currently gets 18: 3 feature releases and 15 bugfix
releases. The lack of bugfix releases is notable. With Plasma if a major
bug is discovered a day after the release (which is common) I can ship a
fix within a week, whereas for Frameworks, it takes a month. This is not
a theoretical problem; it has happened many times over the years.
To me it has always felt strange that the product that benefits most
from stability gets 4 times as many yearly feature releases as Gear and
Plasma, but no bugfix releases at all. And there have been many
occasions oven the years where new features in Frameworks could have
benefited from a bit more QA time in master before final release.
In this sense I find Frameworks' release schedule to be both too fast
and too slow: too fast for new features and too slow for bugfixes.
Shouldn't the product with the strongest stability guarantee ship
bugfixes at least as fast as Plasma?
If Frameworks got a feature release every 2 or 3 months and a guaranteed
bugfix release one week after each feature release, IMO the result would
be much better. We could ship fixes for important bugs faster,
developers would be more incentivized to live on master and therefore
provide their own QA, the period of time during which issues with new
features could be caught before release would be doubled or tripled, and
we could even still have 12 total releases per year.
---
Thus, if we make Gear's release cycle identical to Plasma's to get it
faster bugfixes, and then we also lengthen Frameworks' release cycle so
it gets the bugfix releases it could benefit from while slowing down its
feature releases to improve QA, then the result looks a lot like Carl's
proposal, and that's ultimately why it looks appealing to me.
This doesn't preclude breaking implicit dependencies and relocating
software into groups/release vehicles more suited for them. I don't find
the argument convincing that we ought to deal with pain to make this
happen. IMO we should make decisions about the final form we want, not
based on what we think will torture us into getting there. :)
Nate
