2 kirigami fixes for a point release

[Ben Cooksley]

On Sun, Feb 16, 2020 at 8:35 AM Nate Graham <nate at kde.org> wrote:
>
> 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.

>From my understanding distributions were for the most part happy to
ship Frameworks updates as they came.

While I have not been able to find the thread in question where this
was discussed, I would be very surprised if the distributions you
noted below were not part of that discussion.

Should this have changed, or they have reversed their initial
decision, then we will need to have a conversation with that
distribution as to why they believe it is more appropriate to be
shipping known buggy software and to refuse to ship the fixes to those
bugs.

Should they have initially agreed to distribute the updates and
subsequently changed their policy on it without notifying us then that
also needs to be discussed with them and I think they owe us an
explaination as to why they failed to discuss it with us prior to them
changing their stance (and we changed our policies isn't good enough
as an explaination)

>
>
> > 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

Cheers,
Ben