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
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: New Framework Review: KDAV
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? Cheers, Andreas
Re: New Framework Review: KDAV
On Saturday, 9 November 2019 12:33:54 CET Volker Krause wrote: > Hi, > > during Akademy there was a request to promote KDAV from KDE PIM to > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > would be classified as a functional tier 3 framework. > > So far we have fixed a number of obvious ABI-compatibility issues, removed > QtXml[Patterns] usage from the public interface and relicensed GPL parts > (apart from a bit of test code) to LGPL. The next step would be a more > thorough review to identify changes necessary before becoming a Framework. > > To avoid the last minute invasive changes we ended up doing for > KCalendarCore, I'd propose the following timeline: > > - identify and implement all necessary changes to the API and ABI until the > 20.04 Application release (that includes the still necessary move to the KF5 > library namespace). The rename to the KF5 namespace has been done, if more changes to the ABI are necessary now would be a good time to point those out, so we can integrate them before the 20.04 freeze :) Thanks, Volker > - release KDAV with 20.04 with the final API/ABI that the first KF5 release > will provide as well > - become part of the KF5 release in May or June 2020, release as a drop-in > replacement of the last application release > > In general this is following the same transition process that has been used > for Syndication, KHolidays, KContacts and KCalendarCore as that should cause > minimal disruptions for distributors, but if there's better ideas on how to > handle this, now is a good time to bring this up :) > > Feedback? > > Thanks, > Volker signature.asc Description: This is a digitally signed message part.
