Re: 2 kirigami fixes for a point release
On vendredi 20 mars 2020 12:16:09 CET David Edmundson wrote: > >> > Kirigami seems to be rather unstable, I wonder if anything can be done > >> > to > >> > improve upon that [*]. > >> > >> One important thing seems to have been getting sloppy in those repos; > >> mandatory code reviews. > >> That's an easy thing to enforce, and we know it makes a huge difference > >> to > >> code. > >> > >> Even if no-one comments, the extra delay of it running on your own > >> system delivers a lot. > > > >I fully agree. > > > >(CC'ing the developer lists) > > The situation with code reviews has not changed. > > git log --grep Differential --invert-grep --since 1.month > > In Kirigami is extremely disappointing, and not something we see in > other frameworks. Thanks for noticing (and for the nice git command line!). I'm going to ask more directly than the other David dares doing... @Marco, can you please start using phabricator for all your commits, so that they get reviewed? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: 2 kirigami fixes for a point release
>> > Kirigami seems to be rather unstable, I wonder if anything can be done to >> > improve upon that [*]. > >> One important thing seems to have been getting sloppy in those repos; >> mandatory code reviews. >> That's an easy thing to enforce, and we know it makes a huge difference to >> code. >> >> Even if no-one comments, the extra delay of it running on your own >> system delivers a lot. >I fully agree. > >(CC'ing the developer lists) The situation with code reviews has not changed. git log --grep Differential --invert-grep --since 1.month In Kirigami is extremely disappointing, and not something we see in other frameworks. David
Re: 2 kirigami fixes for a point release
On 2/18/20 1:37 PM, Albert Astals Cid wrote: I still don't see why this is a problem, as said Plasma depends on a myriad of libraries that are building each with their own release model, most probably with no bugfix releases at all either. The "we don't control the whole stack" argument does not apply to parts of the stack that we do control. Improvement is possible even when perfection is not. Incidentally what happens is that those libraries are not buggy, and it seems the Plasma-facing parts of KF5 are, well, let's make them not be. Agreed. Everyone wants less buggy releases. However "less buggy releases" does not fully solve the problem for LTS distros that freeze their KF version. Without point releases of the version they freeze on, we are unable to ship fixes for regressions that do sneak in, and we are unable to ship fixes for old or longstanding issues that we find a way to fix later. We can do both of these things with Plasma. We cannot do either with Frameworks. That's the problem. Ultimately I think we need to decide whether we want to fully support the Plasma LTS or can it. Right now we're in this awkward position where we can hand packagers tarballs with bugfix point releases of Plasma, but not Frameworks. Ultimately this means that there's a class of bug that just doesn't get fixed in the distros with LTS Plasma, which in the end makes us look bad. Nate
Re: 2 kirigami fixes for a point release
On 2/18/20 2:13 PM, Luca Beltrame wrote: In data martedì 18 febbraio 2020 19:26:21 CET, Nate Graham ha scritto: Neon is already an OS, whether or not you want to admit it. It's installed from an ISO. A hardware vendor (Slimbook) is shipping it on Erm, where did I say that in my reply? ;) I merely say that going "Neon or else unsupported" is a very downstream-hostile attitude, ...And where did I say that in my reply? ;) I think we should absolutely continue to support all downstreams, not just Neon; that would be crazy! :) This is in fact why I'm advocating for an LTS Frameworks release to accompany the Plasma LTS release: to better support our non-Neon downstreams who want to freeze on the Plasma LTS releases. Right now we're pushing the job of backporting bugfixes to Frameworks onto them, rather than making it easy by just giving them tarballs. We can argue about what packagers should do, but the best way to get them to do that is to make it easy for them. :) (Neon suffers from the same "LTS problem" for everything that's not KDE-made software, FTR, but that's not the issue I want to raise here) Indeed, and that's the reason why I'm happy with Tumbleweed. I'm quite on board with the seemingly prevailing opinion that discrete LTS releases amount to a broken, defective model. It's just that for the time being we have a product explicitly catering to distros using that broken, defective model. It just seems like an awkward situation that should be addressed one way or another, not left in tension indefinitely. Nate
Re: 2 kirigami fixes for a point release
In data martedì 18 febbraio 2020 19:26:21 CET, Nate Graham ha scritto:
> Neon is already an OS, whether or not you want to admit it. It's
> installed from an ISO. A hardware vendor (Slimbook) is shipping it on
Erm, where did I say that in my reply? ;) I merely say that going "Neon or
else unsupported" is a very downstream-hostile attitude, already seen with
other software ("my way or the highway" in these cases) such as Audacity or
Anki (the latter being one of the most downstream-hostile projects I've ever
known).
(Neon suffers from the same "LTS problem" for everything that's not KDE-made
software, FTR, but that's not the issue I want to raise here)
--
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B
signature.asc
Description: This is a digitally signed message part.
Re: 2 kirigami fixes for a point release
El dimarts, 18 de febrer de 2020, a les 4:03:05 CET, Nate Graham va escriure: > On 2020-02-16 14:43, Albert Astals Cid wrote: > > Maybe i explain myself wrongly, i'm not blaming distros at all. > > > > They made a decision, we/I may agree with them or not, that's *my/our* > > problem, what I was disagreeing is to us having to do extra work because > > someone elses (the distros) decision. > > We already do this: it's called the Plasma LTS product. :-) It's been > specifically created to cater to various distros' desires for an > extended-support product they can ship to users of their own LTS releases. > > But yes, I can also agree with more tests, better stability, moving to > GitLab so tests are run before merging, etc. I think we can all agree > with that. > > However all the autotests in the world will not resolve the fundamental > incompatibility between the Plasma LTS product, which is built around > the release model of extended, ongoing bugfix releases, and Frameworks, > which is built around a rolling release model with no bugfix releases at > all. I still don't see why this is a problem, as said Plasma depends on a myriad of libraries that are building each with their own release model, most probably with no bugfix releases at all either. Incidentally what happens is that those libraries are not buggy, and it seems the Plasma-facing parts of KF5 are, well, let's make them not be. Cheers, Albert
Re: 2 kirigami fixes for a point release
On 2/16/20 2:55 PM, Friedrich W. H. Kossebau wrote: Yes, this has been questioned a few times. Also seeing Plasma LTS used together with a non-LTS Qt is a bit strange. But somehow it seems there has not been enough pain for those using the Plasma LTS to change something. Possibly because distributions simply backport important bug fixes for KF themselves, kind of maintaining their own KF LTS version of the KF version they pinpointed to when they froze the ingredients to their OS. Because they are used to do this for other projects as well, and so miss this could be done in cooperation with upstream. There has been pain. This thread mentions a number of examples, and There were quite a few for the last 5.12 LTS too. But more generally, the pain is baked into Frameworks due to the lack of any bugfix releases. For example Kubuntu 18.04 shipped with the Plasma 5.12 LTS and Frameworks 5.44. That Plasma version has continued to receive bugfix point releases since then. But the Frameworks product has not, and so users have now missed out on two years worth of bugfixes. I don't know about openSUSE, but I know that Kubuntu does not have the resources to backport individual KF bugfixes--I repeatedly requested this as I identified them and none ever got backported. But they do ship point releases for Plasma, so they could ship point releases for an LTS Frameworks version. IMHO distributions using Plasma LTS, Plasma team & other stakeholders should team up here and maintain a matching LTS branch of Frameworks together at the central KDE repos together. Well, and a version also satisfying other clients of KF, like non-workspace applications from KDE. It's not a reason to change normal KF release cycle. I like that idea. So perhaps we could say that the KF version which happens to be the dependency for a Plasma LTS release could have bugfix releases? Would that be reasonable? Nate
Re: 2 kirigami fixes for a point release
On 2/16/20 2:55 PM, Friedrich W. H. Kossebau wrote: Yes, this has been questioned a few times. Also seeing Plasma LTS used together with a non-LTS Qt is a bit strange. But somehow it seems there has not been enough pain for those using the Plasma LTS to change something. Possibly because distributions simply backport important bug fixes for KF themselves, kind of maintaining their own KF LTS version of the KF version they pinpointed to when they froze the ingredients to their OS. Because they are used to do this for other projects as well, and so miss this could be done in cooperation with upstream. There has been pain. This thread mentions a number of examples, and There were quite a few for the last 5.12 LTS too. But more generally, the pain is baked into Frameworks due to the lack of any bugfix releases. For example Kubuntu 18.04 shipped with the Plasma 5.12 LTS and Frameworks 5.44. That Plasma version has continued to receive bugfix point releases since then. But the Frameworks product has not, and so users have now missed out on two years worth of bugfixes. I don't know about openSUSE, but I know that Kubuntu does not have the resources to backport individual KF bugfixes--I repeatedly requested this as I identified them and none ever got backported. But they do ship point releases for Plasma, so they could ship point releases for an LTS Frameworks version. IMHO distributions using Plasma LTS, Plasma team & other stakeholders should team up here and maintain a matching LTS branch of Frameworks together at the central KDE repos together. Well, and a version also satisfying other clients of KF, like non-workspace applications from KDE. It's not a reason to change normal KF release cycle. I like that idea. So perhaps we could say that the KF version which happens to be the dependency for a Plasma LTS release could have bugfix releases? Would that be reasonable? Nate
Re: 2 kirigami fixes for a point release
On 2/17/20 11:08 PM, Luca Beltrame wrote: In data martedì 18 febbraio 2020 04:03:05 CET, Nate Graham ha scritto: think KDE software should be presented to users. Basically, we acknowledge that Neon is already an actual OS--the "KDE OS"--and we Please don't suggest such downstream-hostile solutions, in particular because this failing is entirely upstream. We have already plenty in FOSS, I don't want KDE to be yet another community that "adopts" them. "We messed up so let's make things our way" is not an acceptable approach. Neon is already an OS, whether or not you want to admit it. It's installed from an ISO. A hardware vendor (Slimbook) is shipping it on laptops that people can and do buy. My wife has it installed on her computer. It's an OS as much as any other Ubuntu-derived distro can be considered an OS. I actually happen to use openSUSE Tumbleweed myself instead of Neon for a variety of reasons, and I'm happy with it. I'm not saying "Neon is an OS!" because I think everyone should immediately switch to it and stop using other distros. There's room in the universe of KDE distros for one more that happens to be a first-party product--as evidenced by the fact that Neon has existed for four years and the whole world hasn't come tumbling down. I mean, Microsoft got into the PC hardware business in competition with Dell, HP, Toshiba, et al, and it didn't destroy their business. Far from it: the new entries from Microsoft spurred everyone else to improve their own offerings, broadly lifting the quality of PC hardware for everyone. Nate
Re: 2 kirigami fixes for a point release
> > IMHO distributions using Plasma LTS, Plasma team & other stakeholders should > > team up here and maintain a matching LTS branch of Frameworks together at > > the > > central KDE repos together. Well, and a version also satisfying other > > clients > > of KF, like non-workspace applications from KDE. > > Just to clarify something. "the Plasma team" is not unified in the position that there should be any changes to the current framework's release cycle. > So perhaps we could say that the KF version which happens to be the dependency for a Plasma LTS release could have bugfix releases? Note that next Plasma LTS is a different case anyway as KF6 will be well into development and KF5 branches will be somewhat frozen. The exact details of which is another discussion. David
Re: 2 kirigami fixes for a point release
On 2020-02-16 14:43, Albert Astals Cid wrote: Maybe i explain myself wrongly, i'm not blaming distros at all. They made a decision, we/I may agree with them or not, that's *my/our* problem, what I was disagreeing is to us having to do extra work because someone elses (the distros) decision. We already do this: it's called the Plasma LTS product. :-) It's been specifically created to cater to various distros' desires for an extended-support product they can ship to users of their own LTS releases. But yes, I can also agree with more tests, better stability, moving to GitLab so tests are run before merging, etc. I think we can all agree with that. However all the autotests in the world will not resolve the fundamental incompatibility between the Plasma LTS product, which is built around the release model of extended, ongoing bugfix releases, and Frameworks, which is built around a rolling release model with no bugfix releases at all. If we don't want to change the incompatible way that Frameworks plugs into an LTS Plasma release, and we think our opinions regarding how a distro ought to ship software are valid, then I think it's time for us to take the lead and produce a real reference distro that shows how *we* think KDE software should be presented to users. Basically, we acknowledge that Neon is already an actual OS--the "KDE OS"--and we treat is as such, explicitly advertising it as a fully supported OS suitable for users to install and vendors to ship hardware with (as in fact Slimbook already does!). See also https://phabricator.kde.org/T12707. If we don't want to be so opinionated regarding how software should be released--perhaps out of fear of alienating sponsors that produce LTS distros, for example--then maybe it's time to swallow our opinions, respect the way that those distro partners currently ship software even if we disagree with it, and adjust Frameworks to better support the needs of their LTS releases. Nate
Re: 2 kirigami fixes for a point release
Am Dienstag, 18. Februar 2020, 04:03:05 CET schrieb Nate Graham: > On 2020-02-16 14:43, Albert Astals Cid wrote: > > Maybe i explain myself wrongly, i'm not blaming distros at all. > > > > They made a decision, we/I may agree with them or not, that's *my/our* > > problem, what I was disagreeing is to us having to do extra work because > > someone elses (the distros) decision. > We already do this: it's called the Plasma LTS product. :-) It's been > specifically created to cater to various distros' desires for an > extended-support product they can ship to users of their own LTS releases. > > However all the autotests in the world will not resolve the fundamental > incompatibility between the Plasma LTS product, which is built around > the release model of extended, ongoing bugfix releases, and Frameworks, > which is built around a rolling release model with no bugfix releases at > all. For one, distribution seem to be just fine with that. And it should be them to complain if they cannot make use of Plasma LTS to create a product endorsed by their distribution/operating system flavour users. Why would the package and use Plasma otherwise, if not to create a usable product. They simply create their own KF LTS, by backporting patches which they define important enough to the version of KF they use. Like they do for all the other software where they pinpointed to a certain version and where upstream does not do a matching LTS, starting with the Linux kernel. And as said before, the Plasma team could just maintain some LTS version of KF next to the normal master release branch and the normal releases. That branch could then even be synced with the release schedule pf Plasma LTS, incl. the lifespan, Is there a list of Plasma LTS usages in distributions which are horrible because of important fixes to KF not being backported? Or is this more a theoretical problem you are afraid of seeing the current quality hick-up? Cheers Friedrich
Re: 2 kirigami fixes for a point release
In data martedì 18 febbraio 2020 04:03:05 CET, Nate Graham ha scritto: > think KDE software should be presented to users. Basically, we > acknowledge that Neon is already an actual OS--the "KDE OS"--and we Please don't suggest such downstream-hostile solutions, in particular because this failing is entirely upstream. We have already plenty in FOSS, I don't want KDE to be yet another community that "adopts" them. "We messed up so let's make things our way" is not an acceptable approach. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B signature.asc Description: This is a digitally signed message part.
Re: 2 kirigami fixes for a point release
On Mon, Feb 17, 2020 at 10:55 AM Friedrich W. H. Kossebau wrote: > > Sorry, no time to rewrite to make this short. > > Am Mittwoch, 12. Februar 2020, 21:59:32 CET schrieb Nate Graham: > > [+ frameworks and plasma mailing lists] > > > > On 2020-02-12 11:31, Albert Astals Cid wrote: > > > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va > escriure: > > >> On another note, I have to admit I'm starting to doubt how well our LTS > > >> Plasma product works without a corresponding LTS frameworks release to > > >> support it. We can fix bugs in software that uses the Plasma release > > >> schedule till the cows come home, but if the bug is in Frameworks, users > > >> are stuck with it forever since LTS distros don't typically ship new > > >> Frameworks releases. > > Yes, this has been questioned a few times. Also seeing Plasma LTS used > together with a non-LTS Qt is a bit strange. > But somehow it seems there has not been enough pain for those using the Plasma > LTS to change something. Possibly because distributions simply backport > important bug fixes for KF themselves, kind of maintaining their own KF LTS > version of the KF version they pinpointed to when they froze the ingredients > to their OS. Because they are used to do this for other projects as well, and > so miss this could be done in cooperation with upstream. > > IMHO distributions using Plasma LTS, Plasma team & other stakeholders should > team up here and maintain a matching LTS branch of Frameworks together at the > central KDE repos together. Well, and a version also satisfying other clients > of KF, like non-workspace applications from KDE. > > It's not a reason to change normal KF release cycle. > > BTW, we release our software in variants of GPL. We give distributions lots of > rights by that license to do with the source code what they like, not what > pleases us as authors. So we want to do cooperation here, not get into any > form of commandeering them, as it starts sounding elsewhere in this thread. > > If unsatisfied with the quality, make Plasma a trademark and hand it out only > to distributions which are complying with the standards the Plasma team is > fine with ;) > Oh, look, an iceweasel is running over there... ;) Another option is to withdraw the privilege of pre-release access to packages from the distributions that don't comply. > > > >> Yes yes, they should, and all that--but they don't. > > >> > > >> It seems like we either need to: > > >> - Work on convincing these distros to ship Frameworks versions in a > > >> rolling manner to their LTS users > > >> - Provide an LTS Frameworks product that can receive bugfixes and get > > >> point releases, to support the Plasma LTS product > > >> - Stop misleadingly offering a Plasma LTS product, since everything in > > >> it that comes from Frameworks isn't actually LTS > > > > > > This should not matter, Plasma LTS is built on *lots* of other libraries > > > that are not LTS either. > > > > > > If it matters is because the quality of KF5 releases are not good, that's > > > what should be fixed IMHO. > > Yes, the Frameworks 5.67 release was indeed was quite buggy and > > regression-filled from a Plasma perspective :( > > > > However buggy releases are the proximate cause, not the root cause. We > > have to ask: what causes buggy releases? > > > > I would argue that bugginess is baked into the Frameworks product by > > virtue of its very fast one-month release cycle and lack of beta > > periods, as there are for apps and Plasma. No matter how diligent patch > > review is, regressions always sneak in; that's why QA and beta-testing > > exist. > > This assumes the master branch of KF modules serves the purpose of beta > testing. My understanding is: it does not. And could not be, for the very > reason you gave, too little time and too few testers. > > The master branch's purpose is mainly to collect all changes for the next > release, and serve as reference when merging dependent changes across multiple > repos for CI. It should be in the state of "always releaseable". > > Which also means patches going in should have seen a beta period by the people > doing the patches _before_ merging them, and be well understood in their > potential side-effects. Yes, this also means that for cross-repo/products > developer should have first done some testing for some time with locally > patched variants of all affected repos, if unsure about their changes (say, > removing an unused variable is well understood in effect scope and does not > need lots of testingi). > But by default crowd-sourcing the QA to fellow developers also working against > current master and wanting to test-drive their own changes is not the way to > go. For one they do not know they should test certain things and thus might > not even get close to things, thus not do any testing, or it will conflict > with their own work, when they cannot be sure it was their own change or > someone else's which breaks
Re: 2 kirigami fixes for a point release
On Mon, Feb 17, 2020 at 10:43 AM Albert Astals Cid wrote: > > El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va > escriure: > > On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote: > > > 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. > > > > At the same time, we can only successfully convince distributions to upgrade > > to the monthly KF5 releases if they are stable and don't come with > > regressions. I believe this is true for most of the frameworks, but I'm not > > so > > sure about kirigami/qqc2-desktop-style, based on what I hear (not just the > > recent issue). > > > > Before blaming distros, I believe we have our own backyard to take care of, > > with for sure more systematic use of code reviews and possibly more > > automated > > testing, for those frameworks (for the latter I guess that QtQuick doesn't > > make it easy, but that's part of the problem...). > > Maybe i explain myself wrongly, i'm not blaming distros at all. > > They made a decision, we/I may agree with them or not, that's *my/our* > problem, what I was disagreeing is to us having to do extra work because > someone elses (the distros) decision. Unfortunately users will sadly blame us, saying KDE software is buggy/broken/etc. It therefore falls on us to apply pressure on the distributions making bad decisions and make them correct them. Those distributions that provide a bad experience to our users, and refuse to fix it, are working against us and the goals we are trying to achieve. (I'm not saying that we should bow down to flawed, short sighted and broken distribution policies here, if anyone is bending it should be their policies bending down to us) > > And yes, totally, we need more autotests, and moving to gitlab so tests are > finally run *before* merging stuff. That will come once we have migrated code management and review to Gitlab yes. It wouldn't have helped in the case of Kirigami sadly as there are no unit tests for the things which were broken, but i'm sure it will help in other areas for sure. > > Cheers, > Albert Cheers, Ben > > > > > > > > >
Re: 2 kirigami fixes for a point release
On Mon, Feb 17, 2020 at 4:42 AM David Edmundson 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. > > > > Just to clarify the current policy is: > - frameworks release 5.XX > - plasma beta > - frameworks release 5.XX+1 > - plasma final > > Where 5.XX is the required version for Plasma. We set it as a dep, > just after it gets released. > We've had issues in the past, especially before frameworks had that > 2nd Saturday of the month policy, but I don't think the current rules > have a problem if followed. > > Within the context of this thread, we're dealing with issues that came > up breaking at 5.XX+1, so after the freeze. Not technically new API, > but behavioural changes. Which raises the question of why those behavioural changes were going in so close to the end. If behavioural changes were needed by Plasma they should have been in much earlier - ideally in the 5.XX release. Do we know why they ended up landing at the very last minute? > > David Cheers, Ben
Re: 2 kirigami fixes for a point release
Sorry, no time to rewrite to make this short. Am Mittwoch, 12. Februar 2020, 21:59:32 CET schrieb Nate Graham: > [+ frameworks and plasma mailing lists] > > On 2020-02-12 11:31, Albert Astals Cid wrote: > > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va escriure: > >> On another note, I have to admit I'm starting to doubt how well our LTS > >> Plasma product works without a corresponding LTS frameworks release to > >> support it. We can fix bugs in software that uses the Plasma release > >> schedule till the cows come home, but if the bug is in Frameworks, users > >> are stuck with it forever since LTS distros don't typically ship new > >> Frameworks releases. Yes, this has been questioned a few times. Also seeing Plasma LTS used together with a non-LTS Qt is a bit strange. But somehow it seems there has not been enough pain for those using the Plasma LTS to change something. Possibly because distributions simply backport important bug fixes for KF themselves, kind of maintaining their own KF LTS version of the KF version they pinpointed to when they froze the ingredients to their OS. Because they are used to do this for other projects as well, and so miss this could be done in cooperation with upstream. IMHO distributions using Plasma LTS, Plasma team & other stakeholders should team up here and maintain a matching LTS branch of Frameworks together at the central KDE repos together. Well, and a version also satisfying other clients of KF, like non-workspace applications from KDE. It's not a reason to change normal KF release cycle. BTW, we release our software in variants of GPL. We give distributions lots of rights by that license to do with the source code what they like, not what pleases us as authors. So we want to do cooperation here, not get into any form of commandeering them, as it starts sounding elsewhere in this thread. If unsatisfied with the quality, make Plasma a trademark and hand it out only to distributions which are complying with the standards the Plasma team is fine with ;) Oh, look, an iceweasel is running over there... ;) > >> Yes yes, they should, and all that--but they don't. > >> > >> It seems like we either need to: > >> - Work on convincing these distros to ship Frameworks versions in a > >> rolling manner to their LTS users > >> - Provide an LTS Frameworks product that can receive bugfixes and get > >> point releases, to support the Plasma LTS product > >> - Stop misleadingly offering a Plasma LTS product, since everything in > >> it that comes from Frameworks isn't actually LTS > > > > This should not matter, Plasma LTS is built on *lots* of other libraries > > that are not LTS either. > > > > If it matters is because the quality of KF5 releases are not good, that's > > what should be fixed IMHO. > Yes, the Frameworks 5.67 release was indeed was quite buggy and > regression-filled from a Plasma perspective :( > > However buggy releases are the proximate cause, not the root cause. We > have to ask: what causes buggy releases? > > I would argue that bugginess is baked into the Frameworks product by > virtue of its very fast one-month release cycle and lack of beta > periods, as there are for apps and Plasma. No matter how diligent patch > review is, regressions always sneak in; that's why QA and beta-testing > exist. This assumes the master branch of KF modules serves the purpose of beta testing. My understanding is: it does not. And could not be, for the very reason you gave, too little time and too few testers. The master branch's purpose is mainly to collect all changes for the next release, and serve as reference when merging dependent changes across multiple repos for CI. It should be in the state of "always releaseable". Which also means patches going in should have seen a beta period by the people doing the patches _before_ merging them, and be well understood in their potential side-effects. Yes, this also means that for cross-repo/products developer should have first done some testing for some time with locally patched variants of all affected repos, if unsure about their changes (say, removing an unused variable is well understood in effect scope and does not need lots of testingi). But by default crowd-sourcing the QA to fellow developers also working against current master and wanting to test-drive their own changes is not the way to go. For one they do not know they should test certain things and thus might not even get close to things, thus not do any testing, or it will conflict with their own work, when they cannot be sure it was their own change or someone else's which breaks things, wasting efforts in finding causes. Needing longer beta test phases also hints that some product is not well understood or designed, and things fall apart easily. That needs fixing of the product itself, to become reliably maintainable and expandable. Looking at the reasoning for the recent requests for KF
Re: 2 kirigami fixes for a point release
El diumenge, 16 de febrer de 2020, a les 22:34:51 CET, David Faure va escriure: > On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote: > > 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. > > At the same time, we can only successfully convince distributions to upgrade > to the monthly KF5 releases if they are stable and don't come with > regressions. I believe this is true for most of the frameworks, but I'm not > so > sure about kirigami/qqc2-desktop-style, based on what I hear (not just the > recent issue). > > Before blaming distros, I believe we have our own backyard to take care of, > with for sure more systematic use of code reviews and possibly more automated > testing, for those frameworks (for the latter I guess that QtQuick doesn't > make it easy, but that's part of the problem...). Maybe i explain myself wrongly, i'm not blaming distros at all. They made a decision, we/I may agree with them or not, that's *my/our* problem, what I was disagreeing is to us having to do extra work because someone elses (the distros) decision. And yes, totally, we need more autotests, and moving to gitlab so tests are finally run *before* merging stuff. Cheers, Albert > >
Re: 2 kirigami fixes for a point release
On dimanche 16 février 2020 22:17:17 CET Albert Astals Cid wrote: > 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. At the same time, we can only successfully convince distributions to upgrade to the monthly KF5 releases if they are stable and don't come with regressions. I believe this is true for most of the frameworks, but I'm not so sure about kirigami/qqc2-desktop-style, based on what I hear (not just the recent issue). Before blaming distros, I believe we have our own backyard to take care of, with for sure more systematic use of code reviews and possibly more automated testing, for those frameworks (for the latter I guess that QtQuick doesn't make it easy, but that's part of the problem...). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: 2 kirigami fixes for a point release
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 >
Re: 2 kirigami fixes for a point release
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. 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
Re: 2 kirigami fixes for a point release
> 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. > Just to clarify the current policy is: - frameworks release 5.XX - plasma beta - frameworks release 5.XX+1 - plasma final Where 5.XX is the required version for Plasma. We set it as a dep, just after it gets released. We've had issues in the past, especially before frameworks had that 2nd Saturday of the month policy, but I don't think the current rules have a problem if followed. Within the context of this thread, we're dealing with issues that came up breaking at 5.XX+1, so after the freeze. Not technically new API, but behavioural changes. David
Re: 2 kirigami fixes for a point release
On Sun, Feb 16, 2020 at 8:35 AM Nate Graham 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
Re: 2 kirigami fixes for a point release
On Sat, Feb 15, 2020 at 8:10 AM Nate Graham wrote: > > On 2020-02-13 00:42, Ben Cooksley wrote: > > A better way of approaching this would be to freeze the Frameworks > > version you are going to require API wise at an earlier point in the > > Plasma development cycle. This would allow for a full Frameworks > > release cycle to pass where bugs encountered during the lead up to the > > Plasma release can be fixed. > > > > This version of Frameworks would then be the one that Plasma hard depends > > on. > > We do this; Plasma 5.18 has a minimum Frameworks dependency of 5.66. See > https://community.kde.org/Schedules/Plasma_5#Support_status_by_Release_Series > > The problem here isn't so much API breaks but rather major bugs and UI > regressions. if a framework has a very visible bug or UI regression in > 5.66 of the kind that we would really like to fix, but LTS distros > freeze on that version, then LTS users will be stuck with that issue > forever unless we make a frameworks point release or cajole distro > packagers to backport the fix. > > Rolling release distro users will first see Plasma 5.18 with Frameworks > 5.67, so if that frameworks version has a major bug or UI regression, it > will take a month for the fix to land in users' hands whereas if the > issue were in Plasma itself, we could fix it immediately and users would > get the fix in a week (the first point release is one week after the .0 > release). > > My point is that the schedules just don't really match up if we want to > present a polished finished product and continue to fix bugs for the > lifetime of an LTS release. > 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. 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. > > Nate Regards, Ben
Re: 2 kirigami fixes for a point release
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
Re: 2 kirigami fixes for a point release
On 2020-02-13 00:42, Ben Cooksley wrote: A better way of approaching this would be to freeze the Frameworks version you are going to require API wise at an earlier point in the Plasma development cycle. This would allow for a full Frameworks release cycle to pass where bugs encountered during the lead up to the Plasma release can be fixed. This version of Frameworks would then be the one that Plasma hard depends on. We do this; Plasma 5.18 has a minimum Frameworks dependency of 5.66. See https://community.kde.org/Schedules/Plasma_5#Support_status_by_Release_Series The problem here isn't so much API breaks but rather major bugs and UI regressions. if a framework has a very visible bug or UI regression in 5.66 of the kind that we would really like to fix, but LTS distros freeze on that version, then LTS users will be stuck with that issue forever unless we make a frameworks point release or cajole distro packagers to backport the fix. Rolling release distro users will first see Plasma 5.18 with Frameworks 5.67, so if that frameworks version has a major bug or UI regression, it will take a month for the fix to land in users' hands whereas if the issue were in Plasma itself, we could fix it immediately and users would get the fix in a week (the first point release is one week after the .0 release). My point is that the schedules just don't really match up if we want to present a polished finished product and continue to fix bugs for the lifetime of an LTS release. Nate
Re: 2 kirigami fixes for a point release
On jeudi 13 février 2020 09:46:20 CET David Edmundson wrote: > > Kirigami seems to be rather unstable, I wonder if anything can be done to > > improve upon that [*]. > > One important thing seems to have been getting sloppy in those repos; > mandatory code reviews. > That's an easy thing to enforce, and we know it makes a huge difference to > code. > > Even if no-one comments, the extra delay of it running on your own > system delivers a lot. I fully agree. (CC'ing the developer lists) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: 2 kirigami fixes for a point release
On Thu, Feb 13, 2020 at 9:00 PM Christoph Feck wrote: > > On 02/13/20 08:42, Ben Cooksley wrote: > > Part of the issue here is that Plasma has been known to add API to > > Frameworks and then immediately, without any delay, start using it > > (pretty much always breaking CI in the process) > > > > This means that other changes are likely being pushed into Frameworks > > by Plasma with very little delay as well. > > > > Consequently this means stuff is landing in Framework repositories up > > to the very moment it is released - a release that the next version of > > Plasma (LTS) then depends on. > > > > A better way of approaching this would be to freeze the Frameworks > > version you are going to require API wise at an earlier point in the > > Plasma development cycle. This would allow for a full Frameworks > > release cycle to pass where bugs encountered during the lead up to the > > Plasma release can be fixed. > > You can find bugs in new code best if you are actually using it. I doubt > that delaying using new API would help much. The point here was that when new API is added, it has to be added much earlier in the cycle, so that anything using it gets at a minimum a full month to cycle among our developers and have all the issues worked out - in the next release which is the one that Plasma actually depends on. Currently it is added to Frameworks and started to be used immediately, when Plasma has already released it's first Beta - giving little chance for code to be run on developer systems before it hits end users. Cheers, Ben
Re: 2 kirigami fixes for a point release
On 02/13/20 08:42, Ben Cooksley wrote: Part of the issue here is that Plasma has been known to add API to Frameworks and then immediately, without any delay, start using it (pretty much always breaking CI in the process) This means that other changes are likely being pushed into Frameworks by Plasma with very little delay as well. Consequently this means stuff is landing in Framework repositories up to the very moment it is released - a release that the next version of Plasma (LTS) then depends on. A better way of approaching this would be to freeze the Frameworks version you are going to require API wise at an earlier point in the Plasma development cycle. This would allow for a full Frameworks release cycle to pass where bugs encountered during the lead up to the Plasma release can be fixed. You can find bugs in new code best if you are actually using it. I doubt that delaying using new API would help much.
Re: 2 kirigami fixes for a point release
Hi, > We have to ask: what causes buggy releases? People rushing things in at the last minute, even better if unreviewed. Plasma 5.18 was a prime example of this. Every single time there's drama on Beta tagging day for some last minute change that should go in. To remedy this I wanted Beta feature freeze to be super strict, and even had release people do a "soft feature freeze" even before that. 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. 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? 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... I think you're getting the picture. The problem isn't the release cycle of Frameworks, it's a lack of discipline, and I'm quite sad about that. Cheers Kai Uwe
Re: 2 kirigami fixes for a point release
On Thu, Feb 13, 2020 at 10:00 AM Nate Graham wrote: > > [+ frameworks and plasma mailing lists] > > > On 2020-02-12 11:31, Albert Astals Cid wrote: > > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va > > escriure: > >> Personally I think it would be nice to have > >> 86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma > >> users will be hitting it for the next few years. > >> > >> --- > >> > >> On another note, I have to admit I'm starting to doubt how well our LTS > >> Plasma product works without a corresponding LTS frameworks release to > >> support it. We can fix bugs in software that uses the Plasma release > >> schedule till the cows come home, but if the bug is in Frameworks, users > >> are stuck with it forever since LTS distros don't typically ship new > >> Frameworks releases. > >> > >> Yes yes, they should, and all that--but they don't. > >> > >> It seems like we either need to: > >> - Work on convincing these distros to ship Frameworks versions in a > >> rolling manner to their LTS users Can we please have a list of the offending distributions? > >> - Provide an LTS Frameworks product that can receive bugfixes and get > >> point releases, to support the Plasma LTS product > >> - Stop misleadingly offering a Plasma LTS product, since everything in > >> it that comes from Frameworks isn't actually LTS > > > > This should not matter, Plasma LTS is built on *lots* of other libraries > > that are not LTS either. > > > > If it matters is because the quality of KF5 releases are not good, that's > > what should be fixed IMHO. > > Yes, the Frameworks 5.67 release was indeed was quite buggy and > regression-filled from a Plasma perspective :( Looking at the respin requests I see the following Frameworks as being problematic: - Kirigami - QQC2 Desktop Style This is only a small number of Frameworks. > > However buggy releases are the proximate cause, not the root cause. We > have to ask: what causes buggy releases? Part of the issue here is that Plasma has been known to add API to Frameworks and then immediately, without any delay, start using it (pretty much always breaking CI in the process) This means that other changes are likely being pushed into Frameworks by Plasma with very little delay as well. Consequently this means stuff is landing in Framework repositories up to the very moment it is released - a release that the next version of Plasma (LTS) then depends on. A better way of approaching this would be to freeze the Frameworks version you are going to require API wise at an earlier point in the Plasma development cycle. This would allow for a full Frameworks release cycle to pass where bugs encountered during the lead up to the Plasma release can be fixed. This version of Frameworks would then be the one that Plasma hard depends on. > > I would argue that bugginess is baked into the Frameworks product by > virtue of its very fast one-month release cycle and lack of beta > periods, as there are for apps and Plasma. No matter how diligent patch > review is, regressions always sneak in; that's why QA and beta-testing > exist. > > However because Frameworks has no explicit beta period, the only people > performing QA are those who live on master all the time. The amount of > time for these people to catch regressions can be as short as one day, > for changes committed right before tagging. Even for commits at the very > beginning of a Frameworks release cycle, there will be a maximum of one > month before they ship to users. There simply isn't enough time to > provide adequate QA for Frameworks releases, and the pool of people > doing it is too small. > Changes with the potential to have an impact like that shouldn't be going in a day or two before the tagging/release. > Making users be the QA is mostly okay for rolling release distros whose > users are willing to take on that role: regressions get found and fixed > in the next version and users receive the fixes in one month. But this > model breaks down for LTS release distros that freeze on a specific > frameworks version. If the version they've frozen on is buggy, that's > it. It's buggy forever, unless their we make point releases or their > already overworked packagers go out of the way to search for and > backport fixes. > > The Frameworks release model just doesn't fit for discrete release > distros, especially for the LTS releases. Sometimes it works out better > than other times, but it is a fundamental incompatibility when the > product wants customers to ship new releases continuously, but the > customers want the product frozen to one version with only safe bugfixes > shipped after that. > > Personally I think a lengthier release cycle and discrete beta periods > would really help Frameworks, even in the absence of interest in > creating a product more aligned to our LTS-using customers. > > Nate Regards, Ben
Re: 2 kirigami fixes for a point release
Hello, Since I'm not on release-team I'm discovering this just now. On Wednesday, 12 February 2020 21:59:32 CET Nate Graham wrote: > [+ frameworks and plasma mailing lists] > > On 2020-02-12 11:31, Albert Astals Cid wrote: > > El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va escriure: > >> Personally I think it would be nice to have > >> 86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma > >> users will be hitting it for the next few years. > >> > >> --- > >> > >> On another note, I have to admit I'm starting to doubt how well our LTS > >> Plasma product works without a corresponding LTS frameworks release to > >> support it. We can fix bugs in software that uses the Plasma release > >> schedule till the cows come home, but if the bug is in Frameworks, users > >> are stuck with it forever since LTS distros don't typically ship new > >> Frameworks releases. > >> > >> Yes yes, they should, and all that--but they don't. > >> > >> It seems like we either need to: > >> - Work on convincing these distros to ship Frameworks versions in a > >> rolling manner to their LTS users > >> - Provide an LTS Frameworks product that can receive bugfixes and get > >> point releases, to support the Plasma LTS product > >> - Stop misleadingly offering a Plasma LTS product, since everything in > >> it that comes from Frameworks isn't actually LTS > > > > This should not matter, Plasma LTS is built on *lots* of other libraries > > that are not LTS either. > > > > If it matters is because the quality of KF5 releases are not good, that's > > what should be fixed IMHO. > Yes, the Frameworks 5.67 release was indeed was quite buggy and > regression-filled from a Plasma perspective :( > > However buggy releases are the proximate cause, not the root cause. We > have to ask: what causes buggy releases? Well, I'd first ask, which parts of frameworks are buggy in 5.67? Which are the affected frameworks? If we're talking about a couple in a set of 80, I'd first ask what those have in common that the others don't? I'd look at all that before blaming and overhauling the release model of KF which served us well for the past years. Sorry if there are obvious answers to the questions above, again, I just stepped in. ;-) Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: 2 kirigami fixes for a point release
[+ frameworks and plasma mailing lists] On 2020-02-12 11:31, Albert Astals Cid wrote: El dimecres, 12 de febrer de 2020, a les 15:37:09 CET, Nate Graham va escriure: Personally I think it would be nice to have 86f988434cd657e77cc9429e78f7290ce6b5713d since otherwise LTS Plasma users will be hitting it for the next few years. --- On another note, I have to admit I'm starting to doubt how well our LTS Plasma product works without a corresponding LTS frameworks release to support it. We can fix bugs in software that uses the Plasma release schedule till the cows come home, but if the bug is in Frameworks, users are stuck with it forever since LTS distros don't typically ship new Frameworks releases. Yes yes, they should, and all that--but they don't. It seems like we either need to: - Work on convincing these distros to ship Frameworks versions in a rolling manner to their LTS users - Provide an LTS Frameworks product that can receive bugfixes and get point releases, to support the Plasma LTS product - Stop misleadingly offering a Plasma LTS product, since everything in it that comes from Frameworks isn't actually LTS This should not matter, Plasma LTS is built on *lots* of other libraries that are not LTS either. If it matters is because the quality of KF5 releases are not good, that's what should be fixed IMHO. Yes, the Frameworks 5.67 release was indeed was quite buggy and regression-filled from a Plasma perspective :( However buggy releases are the proximate cause, not the root cause. We have to ask: what causes buggy releases? I would argue that bugginess is baked into the Frameworks product by virtue of its very fast one-month release cycle and lack of beta periods, as there are for apps and Plasma. No matter how diligent patch review is, regressions always sneak in; that's why QA and beta-testing exist. However because Frameworks has no explicit beta period, the only people performing QA are those who live on master all the time. The amount of time for these people to catch regressions can be as short as one day, for changes committed right before tagging. Even for commits at the very beginning of a Frameworks release cycle, there will be a maximum of one month before they ship to users. There simply isn't enough time to provide adequate QA for Frameworks releases, and the pool of people doing it is too small. Making users be the QA is mostly okay for rolling release distros whose users are willing to take on that role: regressions get found and fixed in the next version and users receive the fixes in one month. But this model breaks down for LTS release distros that freeze on a specific frameworks version. If the version they've frozen on is buggy, that's it. It's buggy forever, unless their we make point releases or their already overworked packagers go out of the way to search for and backport fixes. The Frameworks release model just doesn't fit for discrete release distros, especially for the LTS releases. Sometimes it works out better than other times, but it is a fundamental incompatibility when the product wants customers to ship new releases continuously, but the customers want the product frozen to one version with only safe bugfixes shipped after that. Personally I think a lengthier release cycle and discrete beta periods would really help Frameworks, even in the absence of interest in creating a product more aligned to our LTS-using customers. Nate
