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

List:       kde-devel
Subject:    Re: Proposal unify back our release schedules
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2024-04-22 17:19:09
Message-ID: 4384734.kYSaxMfCmK () xps15
[Download RAW message or body]

El dilluns, 22 d'abril del 2024, a les 17:12:46 (CEST), Nate Graham va 
escriure:
> 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. 

I disagree.

In my ideal world, applications should be able to be built against a one year 
old frameworks, before the Qt6 port, Okular's minimum requirement was Ubuntu 
22.04, which makes sure virtually everyone can contribute to it without having 
to build the world.

There's virtually no need in Okular to depend against any new frameworks shiny 
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. 
>
> 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




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