2 kirigami fixes for a point release

Nate Graham nate at kde.org
Fri Feb 14 19:23:49 GMT 2020


On 2020-02-13 00:48, Kai Uwe Broulik wrote:
> To minimize potential Frameworks dependency problems I would even go as 
> far as put Feature freeze on same date as Frameworks tagging date so 
> that no new stuff goes in that could require a Framework change, like 
> the wallpaper JPG vs PNG situation.
> 
> But did people care about all of this? Nope. We had a wallpaper contest 
> that was explicitly scheduled to go in even after the Beta. This is 
> unacceptable and next time we do this I will flat out revert a wallpaper 
> change after the beta.

I agree, we could have and should have done the wallpaper competition 
earlier. However I'm not aware of any user-visible regressions that 
stemmed from the last-minute shuffle for the wallpaper, which is what 
I'm talking about here. Are you?


> Next is this pointless scroll bar visual change. Why did that have to go 
> in a day before the Beta, and - surprise - cause problems all over the 
> stack which require a bunch of Frameworks fixes?

I agree, that should have been deferred to 5.19. Definitely a lack of 
discipline on our behalf.


> Another topic was the KUserFeedback KCM. There had been substantial 
> changes also on release date and this is a feature that must be spot-on 
> and work 120% from day one. The KNewStuffQuick stuff was a substantial 
> change even after Beta freeze...

Like the wallpaper shuffle, I'm not aware of any actual user-visible 
bugs that resulted from this.

In my estimation, the last-minute changes were necessary to get us to 
that 120%, or at least closer than where we were before. Without those 
last-minute kuserfeedback changes, I was worried that the poor 
presentation of what was being transmitted would cause a PR disaster, 
send privacy-conscious people into a panic, and cause other users to 
lose trust in us. As-is, we got one guy on Reddit who wouldn't pipe down 
about it. Without the last-minute changes, I foresaw that times a 
hundred. So at that point it was either introduce last-minute changes or 
punt the whole feature into Plasma 5.19. Which we could have done I 
guess. Maybe we should have. But it seemed like a lot of people really 
wanted it in the LTS release.

And again, nothing actually regressed from that, to my knowledge. What I 
was drawing attention here were regressions and bugs introduced in 
Frameworks that affected people upgrading to Plasma 5.18, such as:

- https://bugs.kde.org/show_bug.cgi?id=417351 [FormLayout positioning 
and width regressions]
- https://bugs.kde.org/show_bug.cgi?id=417127 [Can't turn off Baloo]
- https://bugs.kde.org/show_bug.cgi?id=417511 [Un-maximized dark panels 
have white corners]

Without special point releases or distro packager backporting, LTS users 
could be hitting these issues for years.


Nate


More information about the Plasma-devel mailing list