From kde-devel Mon Apr 22 17:19:09 2024 From: Albert Astals Cid Date: Mon, 22 Apr 2024 17:19:09 +0000 To: kde-devel Subject: Re: Proposal unify back our release schedules Message-Id: <4384734.kYSaxMfCmK () xps15> X-MARC-Message: https://marc.info/?l=kde-devel&m=171380622220461 El dilluns, 22 d=E2=80=99abril del 2024, a les 17:12:46 (CEST), Nate Graham= va=20 escriure: > Ok, so happily I actually see quite a bit of agreement here, regardless > of what else we do. >=20 > 1. Fibonacci bugfix releases are good, and we could benefit from having > Gear adopt these. >=20 > 2. Severing implicit dependencies is a good idea. Shared libraries in > Gear are especially problematic and could benefit from being moved to > Frameworks. >=20 > 3. Fast frameworks releases in some capacity are a benefit and we don't > want to lose this. >=20 >=20 > All in agreement? If so, that would be amazing. >=20 > --- >=20 > 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. >=20 > --- >=20 > 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.=20 I disagree. In my ideal world, applications should be able to be built against a one ye= ar=20 old frameworks, before the Qt6 port, Okular's minimum requirement was Ubunt= u=20 22.04, which makes sure virtually everyone can contribute to it without hav= ing=20 to build the world. There's virtually no need in Okular to depend against any new frameworks sh= iny=20 feature, the existing features are more than enough. Cheers, Albert > This is only realistic if > you use a rolling release distro and are okay with waiting a month to > use the new Frameworks code.=20 > > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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? >=20 > 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. >=20 > --- >=20 > 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. >=20 > 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. :) >=20 > Nate