2 kirigami fixes for a point release

Albert Astals Cid aacid at kde.org
Sun Feb 16 21:17:17 GMT 2020


El dissabte, 15 de febrer de 2020, a les 20:35:23 CET, Nate Graham va escriure:
> On 2020-02-15 11:55, Ben Cooksley wrote:
> > My point above was that the version you decide to freeze on should
> > only be the version you depend on during development.
> > The version you depend on when you release will be the next release of
> > Frameworks (so by freezing on 5.66 for development, it should have had
> > a release-day dependency of 5.67)
> > 
> > The release of Plasma should then take place shortly after the
> > Frameworks version you have a release-day dependency on.
> > 
> > You stagger it like this to ensure that developers are performing a
> > full burn in of the Frameworks version for several weeks on their
> > systems, and to ensure that all the problems they find end up in the
> > Frameworks that users will have on their systems.
> 
> None of this makes a difference for distros that ship LTS Plasma don't 
> ship newer Frameworks versions. No matter how much testing you do, some 
> bugs in Frameworks will slip through and need to be fixed after the 
> release. But the frameworks release cycle has no concept of the 
> post-release bugfix like Apps and Plasma do; instead the expectation is 
> that the distro will just ship a new Frameworks version in a month. This 
> expectation does not match the reality for the distros that want to ship 
> an LTS plasma version and do not ship newer Frameworks versions.

This is their fault, they as a distribution have decided to support a random KDE Frameworks version for longer than we do support it, so they are the ones that should be the job of supporting it.

It's like you are trying to say we should be doing the distributions jobs, what we should be doing is doing our job which is making the best software we can, not spending time accomodating decisions that somebody else took for us, and since distributions often only bring us pain in the shape of not updating versions, etc. IMHO what we should be doing is moving away from distributions model and more into the snap/flatpak model in which we control what we give our users. 

Sadly flatpak doesn't work for non applications and snap is Ubuntu-only-not-really-but-yes-really so for Plasma this doesn't really solver the problem so maybe we should just finally tell our users to start using the good distributions if they care about their user experience. By good meaning those with a rolling KDE software suite or those that actually do backport fixes to the version they have randomly decided to lock onto.

Cheers,
  Albert

> 
> 
> > As for the distributions that are refusing to update Frameworks, do
> > you have a list of those distributions?
> > If they're providing a poor experience to our users then we at the
> > very least should ensure we steer people away from them.
> 
> Oh, you know, just some weird, unimportant little ones, like Debian, 
> Ubuntu/Kubuntu, and openSUSE Leap. ;-) We should definitely make sure 
> that our users don't use *those*; it's not like they're the big heavy 
> hitters of the Linux world that are used in large numbers by 
> corporations and shipped on hardware or anything. :)
> 
> Nate
> 






More information about the Kde-frameworks-devel mailing list