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