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: New Framework Review: KDAV
On Sonntag, 16. Februar 2020 10:29:42 CET Volker Krause wrote: > On Saturday, 15 February 2020 11:42:57 CET Andreas Cord-Landwehr wrote: > > Hi, sorry for this very late mail, missed the call for reviews... > > > > Would it be possible to do some license clarifications before moving kdav > > into the frameworks section? > > > > In mostly all files it is not clear if the LGPL or the GPL is meant > > (stating "GNU Library General Public License" and referring to the GPL > > text at the end of the statement). This license statement is used for all > > files except autotests/fakesever.cpp and autotests/fakeserver.h. > > Luckily, from the copyright statements there are only 3 copyright holders: > > Tobias, Sandro and Gregory. I put all 3 into CC. > > > > @Tobias, Sandro, Gregory: Can you clarify that the code you are holding > > copyright about in this repository is licensed according to > > LGPL-2.0-or-later? > > Thanks for checking! > > We have relicensing approval to LGPL for those three already in https:// > mail.kde.org/pipermail/kde-pim/2019-September/042912.html (thread continues > into the next month), so it's probably something I messed up while executing > the relicensing :) Great! Maybe the simplest way then is to directly replace all affected headers with the text "SPDX-License-Identifier: LGPL-2.0-or-later" and the ambiguity is gone :) Cheers, Andreas
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: New Framework Review: KDAV
On Saturday, 15 February 2020 11:42:57 CET Andreas Cord-Landwehr wrote: > Hi, sorry for this very late mail, missed the call for reviews... > > Would it be possible to do some license clarifications before moving kdav > into the frameworks section? > > In mostly all files it is not clear if the LGPL or the GPL is meant (stating > "GNU Library General Public License" and referring to the GPL text at the > end of the statement). This license statement is used for all files except > autotests/fakesever.cpp and autotests/fakeserver.h. > Luckily, from the copyright statements there are only 3 copyright holders: > Tobias, Sandro and Gregory. I put all 3 into CC. > > @Tobias, Sandro, Gregory: Can you clarify that the code you are holding > copyright about in this repository is licensed according to > LGPL-2.0-or-later? Thanks for checking! We have relicensing approval to LGPL for those three already in https:// mail.kde.org/pipermail/kde-pim/2019-September/042912.html (thread continues into the next month), so it's probably something I messed up while executing the relicensing :) Regards, Volker signature.asc Description: This is a digitally signed message part.
