Re: Moving KWeatherCore to Gear
On Wednesday, 12 June 2024 23:35:01 CEST Albert Astals Cid wrote: > El dilluns, 27 de maig del 2024, a les 17:36:06 (CEST), Volker Krause va > > escriure: > > Hi, > > > > I'd like to propose adding KWeatherCore [1] to the Gear release > > automation. > > It's main consumer (KWeather) is already in Gear, so for that alone it > > makes sense IMHO. I'd also like to replace the weather code in Itinerary > > with that eventually, for which synchronized and predictable releases > > would also be helpful. > > > > I've checked with Devin on #plasma-mobile a couple of days ago, and he'd > > be > > ok with this. > > More than two weeks have passed and no one seems to disagree. > > Can you prepare a MR like > https://invent.kde.org/sysadmin/release-tools/-/merge_requests/50/diffs > ? done: https://invent.kde.org/sysadmin/release-tools/-/merge_requests/51 and related: https://invent.kde.org/libraries/kweathercore/-/merge_requests/78 Regards, Volker signature.asc Description: This is a digitally signed message part.
Moving KWeatherCore to Gear
Hi, I'd like to propose adding KWeatherCore [1] to the Gear release automation. It's main consumer (KWeather) is already in Gear, so for that alone it makes sense IMHO. I'd also like to replace the weather code in Itinerary with that eventually, for which synchronized and predictable releases would also be helpful. I've checked with Devin on #plasma-mobile a couple of days ago, and he'd be ok with this. Thanks, Volker [1] https://invent.kde.org/libraries/kweathercore signature.asc Description: This is a digitally signed message part.
Re: Moving KUnifiedPush to KDE Gear
On Montag, 15. April 2024 23:22:00 CEST Albert Astals Cid wrote: > El dilluns, 15 d’abril del 2024, a les 18:06:30 (CEST), Volker Krause va > > escriure: > > Hi, > > > > I'd like to propose the KUnifiedPush library > > (https://invent.kde.org/libraries/ kunifiedpush) for inclusion in KDE > > Gear. > > My answer when someone else asked the same question for other apps on Matrix > this morning. > > I'd say feels a bit late with dependency freeze in 3 days and freeze freeze > in 10. > > I'd prefer 2 weeks before dependency freeze, could live with 2 weeks before > freeze freeze. [1] > > Can we wait for 24.08 for this? Fair enough, we can fill the gap with manual releases if needed. Regards, Volker signature.asc Description: This is a digitally signed message part.
Moving KUnifiedPush to KDE Gear
Hi, I'd like to propose the KUnifiedPush library (https://invent.kde.org/libraries/ kunifiedpush) for inclusion in KDE Gear. This was stalled for some time but we finally have a default server installation thanks to Carl, so this is now actually useful for people not running their own infrastructure as well. There's two users of this already, Neochat and Tokodon, both have it as an optional dependency at the moment. Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: Report of packaging issues with mega release
Thanks, these reports are very helpful! On Samstag, 2. Dezember 2023 00:12:04 CET Antonio Rojas wrote: > This list is based on the beta tarballs with some (already committed) fixes > on top to fix build with latest kdiagram and plasma-activities. > > Frameworks: > > - ktexteditor: conflicts with KF5 > > /usr/share/dbus-1/system-services/org.kde.ktexteditor.katetextbuffer.servic > e /usr/share/dbus-1/system.d/org.kde.ktexteditor.katetextbuffer.conf > /usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.policy https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/643 > Gear: > - kpublictransport: Qt5/6 versions collide. Qt5 version needed by > kosmindoormap and itinerary. Blocks packaging itinerary. I hope we get Itinerary switched in time as well, which would resolve this and the Quotient issue below. That was mainly blocked by Android Qt6 packages not working at all until recently, but we made good progress on that recently. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: MegaRelease Freezes - Re: Release schedule proposal for the February MegaRelease
On Dienstag, 26. September 2023 00:29:21 CEST Albert Astals Cid wrote: > El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals Cid > va > escriure: > > https://community.kde.org/Schedules/February_2024_MegaRelease > > > > Beta 1 is during Qt World Summit that is not ideal but I guess doable? > > > > I'll answer to this email with a few other emails things i thing we have > > to > > discuss to try to organize the discusion earlier. > > Do we want common times for dependency/feature/string freezes for all the 3 > products or different for each of them? The suggestion for Frameworks would be aiming at an API freeze for the first alpha release in November. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear repositories switching to Qt6 - Re: Release schedule proposal for the February MegaRelease
On Dienstag, 26. September 2023 00:32:50 CEST Albert Astals Cid wrote: > El dimarts, 26 de setembre de 2023, a les 0:28:15 (CEST), Albert Astals Cid > va > escriure: > > https://community.kde.org/Schedules/February_2024_MegaRelease > > > > Beta 1 is during Qt World Summit that is not ideal but I guess doable? > > > > I'll answer to this email with a few other emails things i thing we have > > to > > discuss to try to organize the discusion earlier. > > Until how kate do we allow KDE Gear repositories to switch to Qt6? My understanding would be that this is a dependency version change and thus this is already covered by the dependency freeze? Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KHealthCertificate in Gear
On Dienstag, 5. September 2023 02:03:19 CEST Justin Zobel wrote: > I would certainly prefer it go into Frameworks than Gear as I think Gear > should be only applications. It's odd enough that Plasma depends on > kexiv and that's in Gear. Of the ~250 Gear modules ~50 are libraries, and that's not even counting plugin or other non-application modules. > On 5/9/23 06:34, Albert Astals Cid wrote: > > El dilluns, 4 de setembre de 2023, a les 17:16:29 (CEST), Volker Krause va > > > > escriure: > >> On Dienstag, 29. August 2023 00:07:34 CEST Albert Astals Cid wrote: > >>> El divendres, 25 d’agost de 2023, a les 16:15:13 (CEST), Volker Krause > >>> va > >>> > >>> escriure: > >>>> Hi, > >>>> > >>>> it looks like we missed KHealthCertificate (https://invent.kde.org/pim/ > >>>> khealthcertificate) when dissolving Mobile Gear, and it's currently not > >>>> covered by automated releases. This went unnoticed as it hasn't gotten > >>>> API > >>>> changes recently, only a few data updates, but I'd like to fix this as > >>>> we > >>>> have things depending on it. > >>>> > >>>> So I'd suggest we include it in 23.12, assuming we don't want to add > >>>> things > >>>> to the 23.08 series at this point. > >>> > >>> Seems it was done on purpose? > >>> > >>> https://invent.kde.org/teams/plasma-mobile/issues/-/issues/186 > >>> > >>> I don't particularly mind if it goes in KDE Gear but whoever wrote that > >>> table seems that decided it's not what was wanted for > >>> KHealthCertificate? > >> > >> oh, interesting... why/how was that decided? > > > > I've no idea :D > > > > Devin Lin (cc-ed) wrote that issue, so maybe he knows? > > > > Cheers, > > > >Albert > >> > >> I don't remember being involved > >> in that, and I'm kinda the maintainer, and responsible for one of its > >> main > >> consumers... > >> > >> It does seem to be based on the assumption of moving to KF instead of > >> Gear > >> though, which isn't really necessary nor intended here. > >> > >> Regards, > >> Volker signature.asc Description: This is a digitally signed message part.
Re: KHealthCertificate in Gear
On Dienstag, 29. August 2023 00:07:34 CEST Albert Astals Cid wrote: > El divendres, 25 d’agost de 2023, a les 16:15:13 (CEST), Volker Krause va > > escriure: > > Hi, > > > > it looks like we missed KHealthCertificate (https://invent.kde.org/pim/ > > khealthcertificate) when dissolving Mobile Gear, and it's currently not > > covered by automated releases. This went unnoticed as it hasn't gotten API > > changes recently, only a few data updates, but I'd like to fix this as we > > have things depending on it. > > > > So I'd suggest we include it in 23.12, assuming we don't want to add > > things > > to the 23.08 series at this point. > > Seems it was done on purpose? > > https://invent.kde.org/teams/plasma-mobile/issues/-/issues/186 > > I don't particularly mind if it goes in KDE Gear but whoever wrote that > table seems that decided it's not what was wanted for KHealthCertificate? oh, interesting... why/how was that decided? I don't remember being involved in that, and I'm kinda the maintainer, and responsible for one of its main consumers... It does seem to be based on the assumption of moving to KF instead of Gear though, which isn't really necessary nor intended here. Regards, Volker signature.asc Description: This is a digitally signed message part.
KHealthCertificate in Gear
Hi, it looks like we missed KHealthCertificate (https://invent.kde.org/pim/ khealthcertificate) when dissolving Mobile Gear, and it's currently not covered by automated releases. This went unnoticed as it hasn't gotten API changes recently, only a few data updates, but I'd like to fix this as we have things depending on it. So I'd suggest we include it in 23.12, assuming we don't want to add things to the 23.08 series at this point. Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: KF5 release schedule
On Samstag, 5. August 2023 16:53:58 CEST David Faure wrote: > Hi everyone, > > Given the small size of the changelog these last two months (see attached) > I suggest that we move to a 2-months release schedule for KF5. > > Maybe even 3 months? Let me know, I don't mind either way. the suggestion from the KF6 meeting would be to continue on the 1 month cycle until the first KF6 release (in the best case that's just 3 releases away now), as besides regular bugfixes we might also still need forward compatibility fixes for co-existence with KF6. After that we can then increase the interval, either using a fixed 2 or 3 month cycle, or a continuously increasing scheme like the Plasma patch level releases. Would that be ok for you? Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear and KF6
On Tuesday, 7 March 2023 01:05:50 CET Albert Astals Cid wrote: > El dilluns, 6 de març de 2023, a les 17:04:12 (CET), Volker Krause va > > escriure: > > Hi, > > > > with Plasma switched to KF6, the question what to do for other modules is > > coming up as well. Manually released modules have various options there I > > guess, but for everything covered by the KDE Gear release automation we > > probably want to standardize the process to not break automation too much, > > regarding branching at least (for the timeline I expect we need more > > flexibility). > > > > I have seen several scenarios mentioned/discussed so far: > > > > (1) The switch to 6 happens within one release cycle. That's the easy case > > and probably has minimal to no impact on release automation. Unlikely to > > be > > relevant for 23.08 already, but probably relevant starting from 23.12. > > I don't think this is feasible, we had years of kdelibs4+KF5 releases for > KDE Applications. Right, certainly not for all of Gear at once! For individual smaller modules I do think completing the switch within one cycle is definitely feasible though, especially when starting from an already existing dual-version state. Basically option 2a with an extremely short lived kf6 branch. > > (2) Switching needs more than one cycle. This is more likely to be > > relevant > > for 23.08 already. > > > > (2a) The migration happens in a separate kf6 branch: > > - 3 concurrent branches > > + no impact on the release automation > > + continuous releases for users > > > > (2b) The migration happens in the master branch, additional patch releases > > are made from the last release branch (ie. instead of e.g. 23.08.0 there > > would be a 23.04.4) > > + no change to existing branching patterns for developers > > - more significant change to release automation > > + continuous releases for users > > > > (2c) Migration in master branch, so further releases > > + no changes to existing branching patterns > > + presumably minimal impact to release automation > > - no bugfix releases for users > > > > What are your thoughts on this? > > I think 2a worked well on the kf5 migration and should serve us well here > too. Leaving aside the orthogonal discussion on whether/when to drop things from Gear, it seems that is the way to go then. Thanks, Volker signature.asc Description: This is a digitally signed message part.
KDE Gear and KF6
Hi, with Plasma switched to KF6, the question what to do for other modules is coming up as well. Manually released modules have various options there I guess, but for everything covered by the KDE Gear release automation we probably want to standardize the process to not break automation too much, regarding branching at least (for the timeline I expect we need more flexibility). I have seen several scenarios mentioned/discussed so far: (1) The switch to 6 happens within one release cycle. That's the easy case and probably has minimal to no impact on release automation. Unlikely to be relevant for 23.08 already, but probably relevant starting from 23.12. (2) Switching needs more than one cycle. This is more likely to be relevant for 23.08 already. (2a) The migration happens in a separate kf6 branch: - 3 concurrent branches + no impact on the release automation + continuous releases for users (2b) The migration happens in the master branch, additional patch releases are made from the last release branch (ie. instead of e.g. 23.08.0 there would be a 23.04.4) + no change to existing branching patterns for developers - more significant change to release automation + continuous releases for users (2c) Migration in master branch, so further releases + no changes to existing branching patterns + presumably minimal impact to release automation - no bugfix releases for users What are your thoughts on this? Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Respins festival
There's another candidate unfortunately: https://invent.kde.org/frameworks/ extra-cmake-modules/-/commit/34fd474aa9c29ac519767446fce132139df313b3 This fixes the build of native Android components and APKs with Qt 5.15.8. No impact on other platforms (it's in a file only used on Android), but for Android it's fatal. On Mittwoch, 11. Januar 2023 23:53:49 CET David Faure wrote: > kio v5.102.0-rc2 > 60787ea2f23ae5c65ea6bf777ed0b1b0eb342465 > 6a9417c01ecf6681ee41ad0d3f7723dc9dbbbe620cd4bead70b4ebae068e716b > sources/kio-5.102.0.tar.xz > > kwidgetsaddons v5.102.0-rc2 > 635e82a021fcaed624b2779d32cf3f54c4abedde > 51d69722986355df6fde5eb2d05379469d01c8dc29577370bc589c263cb2d6d2 > sources/kwidgetsaddons-5.102.0.tar.xz > > sonnet v5.102.0-rc2 > 61d53f33c2c325842ea7285fad1a17546780f3fc > 0eaa21b763fcf6607fa1db1789115484fcd58e993a0dfb1cd2638f0d288aac11 > sources/sonnet-5.102.0.tar.xz signature.asc Description: This is a digitally signed message part.
Re: KDE Gear 22.12 RC is released
On Montag, 28. November 2022 10:21:42 CET Christophe Giboudeaux wrote: > On vendredi 25 novembre 2022 14:08:19 CET Heiko Becker wrote: > > The release candidate for KDE Gear 22.12 is now available at > > https://download.kde.org/unstable/release-service/22.11.90/ > > > > Please report any issues, release of the final version is planned for > > December 8. > > kitinerary's extractorscriptenginetest test fails when the package is built > without ZXing: > > https://invent.kde.org/-/snippets/2429 Should be fixed by https://invent.kde.org/pim/kitinerary/-/commit/ 1f8aa6c9aceb477d6be6de441c33dbe585bef510 The only reason ZXing is optional is that it hasn't been installed on all our CI platforms, it should be mandatory once that is eventually fixed. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear 22.03 Beta is released
On Samstag, 19. März 2022 12:33:33 CET Albert Astals Cid wrote: > El dissabte, 19 de març de 2022, a les 9:02:35 (CET), Tobias C. Berner va escriure: > > 2) libkgapi requires kf5-5.92 but does not say so in CMakeLists.txt > > I've updated the minimum required version now. > > On a personal note, kdepim people, I think the world would appreciate if you > don't increase the minimum KF5 release so late in the cycle (yes, I know > this particular change is within the rules we have given ourselves) "for no > reason", because if i look at > https://invent.kde.org/pim/libkgapi/-/commit/b5eeafe88c4066386dba866246102e > 2ea338bc4c it doesn't seem like it is really worth it reducing the amount of > people that can compile our software that much. I did fix this problem in a few repos, I missed libkgapi was also affected, sorry about that. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE 21.08 dependency freeze in
On Freitag, 2. Juli 2021 08:59:08 CEST Heiko Becker wrote: > Dependency freeze for KDE Gear 21.08 is in six days (July 8, 23:59 UTC), > please make sure to update all the needed dependencies before that date. This would mean depending on KF5 5.84 is not an option, right? That would only become available on July 10 according to schedule. It's a bit unfortunate in case of Itinerary, which is badly affected by Kirigami's CardListView changes in 5.84. The older and new versions can only be supported while degrading performance by disabling delegate recycling, so requiring the new one and avoiding such workarounds would be preferable. Regards, Volker > Next interesting dates: > July 15: 21.08 Freeze and Beta (21.07.80) tag & release > ... > August 12: 21.08.0 Release > > More at: > https://community.kde.org/Schedules/KDE_Gear_21.08_Schedule > > Regards, > Heiko signature.asc Description: This is a digitally signed message part.
Inclusion of KOpeningHours in the release service
Hi, having passed the kdereview process, I'd like to ask for the kopeninghours module to be included in the release service for 21.04. Besides kosmindoormap and itinerary using this (currently optional, pending inclusion into the release service), this is also already in use by the OSM Osmose validator. Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: KCalendarCore Require Libcal 3.0
On Dienstag, 17. November 2020 18:10:22 CET Allen Winter wrote: > Release Team, > > Unless there are objections, I'd like to require libical v3.0 in > kcalendarcore. libical v3.0.0 was released over 3 years ago (28 Oct 2017) > > @Volker: you are the kcalendarcore maintainer. any objections? Wait, what!? I always thought that was you :D We should fix that if it's noted wrongly somewhere. Regards, Volker
Re: Inclusion of KPublicTransport, KOSMIndoorMap and Itinerary in the release service
On Sonntag, 1. November 2020 12:02:29 CET Albert Astals Cid wrote: > El divendres, 30 d’octubre de 2020, a les 16:09:11 CET, Volker Krause va escriure: > > Hi, > > > > assuming the on-going review process for KOSMIndoorMap wont find any > > blockers in the next few days anymore, I'd like to ask for the following > > three modules to be included in the release service for 20.12: > > > > - kpublictransport > > - kosmindoormap > > - itinerary > > Some of these seems that never had a release, we usually recommend doing a > few standalone releases before joining the release service. > > Are you sure you want to skip that and join straightaway? Relying on manual releases obviously didn't work for the past 3 years or so, which is what I'm trying to fix here. In terms of update speed in case of a sudden increase of usage, that is IMHO less depending on the release here but on us managing to put this into the official app stores (given this is solely a mobile application), and doing that in an automated and reproduceable fashion is still further away. So, unless there are objections, I'd suggest to go straight to release service. Thanks, Volker
Inclusion of KPublicTransport, KOSMIndoorMap and Itinerary in the release service
Hi, assuming the on-going review process for KOSMIndoorMap wont find any blockers in the next few days anymore, I'd like to ask for the following three modules to be included in the release service for 20.12: - kpublictransport - kosmindoormap - itinerary All of them should already have the release service version number setup. Thanks, Volker
Re: New Framework Review: KDAV
This has all been executed now, including the move on Gitlab and the necessary changes to the dependency metadata. So unless I'm missing something this should be all done now and we'll have KDAV in KF 5.72 as a drop-in replacement for the one released with 20.04 :) Thanks everyone for helping with this! Volker On Sunday, 14 June 2020 11:53:42 CEST Albert Astals Cid wrote: > El diumenge, 14 de juny de 2020, a les 10:17:01 CEST, Ben Cooksley va escriure: > > On Sun, Jun 14, 2020 at 8:03 PM Volker Krause wrote: > > > With both 20.04.2 and 5.71.0 out I think it's now time to do this move. > > > > > > What extra steps do we need to take now that the framework/application > > > distinction exists in Gitlab as well? I guess this is the first case of > > > a > > > post-migration move. Also, what is the impact on the 20.04.3 release > > > when we move this in Gitlab? > > > > You'll need to file a Sysadmin ticket requesting we relocate the > > repository from it's current home in pim/ to frameworks/ > > Gitlab will provide a redirect for this automatically, so existing > > urls and clones won't be affected by this - although they will be > > given a notice that it has moved. > > > > Systems such as scripty won't be impacted by this as they use the > > stable repository identifier. > > > > In terms of the Release Service 20.04.3 release, Albert/Christoph will > > need to comment on this. > > It shouldn't, the release service scripts don't care about the subdir repos > are in, and given gitlab follows moves, we shouldn't not have a problem > either with things like pushing tags, etc. > > Cheers, > Albert > > > > Thanks, > > > Volker > > > > Cheers, > > Ben > > > > > On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote: > > > > The remaining issues that didn't change ABI anymore (movable value > > > > types, > > > > hide private methods/slots inside the private classes, etc) have long > > > > since > > > > been addressed. > > > > > > > > I think there's two possible time slots to actually execute the move > > > > to > > > > frameworks now: > > > > * ASAP, for the June release. > > > > * For the July release, just in time for the 20.08 dependency freeze. > > > > > > > > Opinions? > > > > > > > > Thanks, > > > > Volker > > > > > > > > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote: > > > > > Thanks for the review! We are cutting it close again with the 20.04 > > > > > deadline, but fortunately most of these findings aren't ABI-breaking > > > > > :) > > > > > > > > > > The result was discussed in more detail at the (virtual) PIM sprint, > > > > > summary below for the record. > > > > > > > > > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > > > > > > Hello, > > > > > > > > > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > > > > > > 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 ne
Re: New Framework Review: KDAV
With both 20.04.2 and 5.71.0 out I think it's now time to do this move. What extra steps do we need to take now that the framework/application distinction exists in Gitlab as well? I guess this is the first case of a post-migration move. Also, what is the impact on the 20.04.3 release when we move this in Gitlab? Thanks, Volker On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote: > The remaining issues that didn't change ABI anymore (movable value types, > hide private methods/slots inside the private classes, etc) have long since > been addressed. > > I think there's two possible time slots to actually execute the move to > frameworks now: > * ASAP, for the June release. > * For the July release, just in time for the 20.08 dependency freeze. > > Opinions? > > Thanks, > Volker > > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote: > > Thanks for the review! We are cutting it close again with the 20.04 > > deadline, but fortunately most of these findings aren't ABI-breaking :) > > > > The result was discussed in more detail at the (virtual) PIM sprint, > > summary below for the record. > > > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > > > Hello, > > > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > > > 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). > > > > > > I'm likely late to the party, but here is what I found by looking at > > > KDAV > > > > > > master today (first day of the KDE PIM sprint): > > > * There's a few private methods or Q_SLOTS that I'd hide completely by > > > > > > moving them to the d-pointer, for the slots we're using type safe > > > connects > > > so they don't even need to be marked as slots at all; > > > > Cosmetic with no ABI impact, we can do that post 20.04 still. > > > > > * Is it worth making DavCollection moveable? It's only copyable right > > > now; > > > > Probably yes, that's new API with no ABI break, so we can do that post > > 20.04 as well. > > > > > * We might want to do something about "ctag" in DavCollection it's a > > > bit > > > > > > obscure as a name (and the API doc doesn't help), also it seems to not > > > be > > > an official standard (while being widely supported) and there's the > > > sync-token mechanism which has a RFC (RFC6578); > > > > I have no idea what ctag is (I am only doing the technical work needed to > > turn this into a framework, I didn't write this library). > > > > > * Why isn't DavCollectionModifyJob using DavCollection somehow? (might > > > just > > > > > > be my ignorance but I find it surprising that it is solely based on a > > > property mechanism); > > > > I think this is to be able to control which properties get changed, rather > > than sending the full set of them. > > > > > * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter > > > on > > > > > > its collectionDiscovered signal, is it really necessary? if it has to > > > stay, > > > shouldn't be at least documented? or at least a safer type than int? > > > > Fixed in https://phabricator.kde.org/D28564 and > > https://phabricator.kde.org/ D28566 > > > > > * DavCollectionsMultiFetchJob is inconsist
Re: New Framework Review: KDAV
The remaining issues that didn't change ABI anymore (movable value types, hide private methods/slots inside the private classes, etc) have long since been addressed. I think there's two possible time slots to actually execute the move to frameworks now: * ASAP, for the June release. * For the July release, just in time for the 20.08 dependency freeze. Opinions? Thanks, Volker On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote: > Thanks for the review! We are cutting it close again with the 20.04 > deadline, but fortunately most of these findings aren't ABI-breaking :) > > The result was discussed in more detail at the (virtual) PIM sprint, summary > below for the record. > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > > Hello, > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > > 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). > > > > I'm likely late to the party, but here is what I found by looking at KDAV > > > > master today (first day of the KDE PIM sprint): > > * There's a few private methods or Q_SLOTS that I'd hide completely by > > > > moving them to the d-pointer, for the slots we're using type safe connects > > so they don't even need to be marked as slots at all; > > Cosmetic with no ABI impact, we can do that post 20.04 still. > > > * Is it worth making DavCollection moveable? It's only copyable right > > now; > > Probably yes, that's new API with no ABI break, so we can do that post 20.04 > as well. > > > * We might want to do something about "ctag" in DavCollection it's a bit > > > > obscure as a name (and the API doc doesn't help), also it seems to not be > > an official standard (while being widely supported) and there's the > > sync-token mechanism which has a RFC (RFC6578); > > I have no idea what ctag is (I am only doing the technical work needed to > turn this into a framework, I didn't write this library). > > > * Why isn't DavCollectionModifyJob using DavCollection somehow? (might > > just > > > > be my ignorance but I find it surprising that it is solely based on a > > property mechanism); > > I think this is to be able to control which properties get changed, rather > than sending the full set of them. > > > * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on > > > > its collectionDiscovered signal, is it really necessary? if it has to > > stay, > > shouldn't be at least documented? or at least a safer type than int? > > Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/ > D28566 > > > * DavCollectionsMultiFetchJob is inconsistent as it's not using > > Q_DECLARE_PRIVATE; > > That's due to using KJob as a base directly. > > Subsequent discussion suggested this should be a KCompositeJob, David is > taking care of this. > > > * KDAV::Error would benefit from more apidox; > > Yes, not blocked by the 20.04 freeze though. > > > * Is it worth making DavItem moveable? It's only copyable right now; > > See above, same as DavCollection. > > > * Same comment about etag for DavItem than the ctag one for DavCollection > > See above, same as ctag. > > > * I'd be tempted to move all the protected methods of DavJobBase on its > > d- > > > > pointer, the job subclasses would have access to them anyway, it'd make > > sense to put them protected in the header only if we expect subclasses > > outside of the lib (and I doubt this is actually supported); > > ABI impact mitigated by https://phabricator.kde.org/D
Re: New Framework Review: KDAV
Thanks for the review! We are cutting it close again with the 20.04 deadline, but fortunately most of these findings aren't ABI-breaking :) The result was discussed in more detail at the (virtual) PIM sprint, summary below for the record. On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > Hello, > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > 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). > > I'm likely late to the party, but here is what I found by looking at KDAV > master today (first day of the KDE PIM sprint): > * There's a few private methods or Q_SLOTS that I'd hide completely by > moving them to the d-pointer, for the slots we're using type safe connects > so they don't even need to be marked as slots at all; Cosmetic with no ABI impact, we can do that post 20.04 still. > * Is it worth making DavCollection moveable? It's only copyable right now; Probably yes, that's new API with no ABI break, so we can do that post 20.04 as well. > * We might want to do something about "ctag" in DavCollection it's a bit > obscure as a name (and the API doc doesn't help), also it seems to not be an > official standard (while being widely supported) and there's the sync-token > mechanism which has a RFC (RFC6578); I have no idea what ctag is (I am only doing the technical work needed to turn this into a framework, I didn't write this library). > * Why isn't DavCollectionModifyJob using DavCollection somehow? (might just > be my ignorance but I find it surprising that it is solely based on a > property mechanism); I think this is to be able to control which properties get changed, rather than sending the full set of them. > * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on > its collectionDiscovered signal, is it really necessary? if it has to stay, > shouldn't be at least documented? or at least a safer type than int? Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/ D28566 > * DavCollectionsMultiFetchJob is inconsistent as it's not using > Q_DECLARE_PRIVATE; That's due to using KJob as a base directly. Subsequent discussion suggested this should be a KCompositeJob, David is taking care of this. > * KDAV::Error would benefit from more apidox; Yes, not blocked by the 20.04 freeze though. > * Is it worth making DavItem moveable? It's only copyable right now; See above, same as DavCollection. > * Same comment about etag for DavItem than the ctag one for DavCollection See above, same as ctag. > * I'd be tempted to move all the protected methods of DavJobBase on its d- > pointer, the job subclasses would have access to them anyway, it'd make > sense to put them protected in the header only if we expect subclasses > outside of the lib (and I doubt this is actually supported); ABI impact mitigated by https://phabricator.kde.org/D28562 so we can clean this up after 20.04. > * It needs to decide between Qt smart pointers or STL ones I think, found a > bit of both so far (I'd lean toward STL ones but maybe that's just me); Also fixed by https://phabricator.kde.org/D28562. > * Make DavUrl moveable? See above, same as DavCollection and DavItem. > * EtagCache probably shouldn't have anything protected, also, why is it a > QObject at all? This is why: https://lxr.kde.org/source/kde/pim/kdepim-runtime/resources/dav/ resource/akonadietagcache.cpp > * Are we sure we want to return a QLatin1String in ProtocolInfo? this > strike me as an odd choice. Fixed in https://phabricator.kde.org/D28563. > Overall apidox would likely need a big pass of cleanups as well. > I think that's it from me. I hope we managed to address everything on short notice that would require ABI breaks after the 20.04 release (and thus cause a delay of the frameworks move Volker signature.asc Description: This is a digitally signed message part.
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.
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.
Re: KDE Frameworks 5.65.0
On Sunday, 8 December 2019 11:45:05 CET David Faure wrote: > Dear packagers, > > KDE Frameworks 5.65.0 has been uploaded to the usual place. > > New frameworks: KQuickCharts. > > Public release next Saturday. > > Thanks for the packaging work! https://bugs.kde.org/show_bug.cgi?id=233628 suggests that not having https:// phabricator.kde.org/D25371 in KIO can cause problems with certain self-signed certificate scenarios. Worth a respin? (I delayed merging that to post 5.65 as I assumed it to not be needed but being a regression risk in itself, seems the opposite is true...) Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: Add kdeconnect-kde to release service
On Thursday, 12 December 2019 18:44:30 CET Nicolas Fella wrote: > On Donnerstag, 12. Dezember 2019 18:17:45 CET Volker Krause wrote: > > I think in general it would be very nice to have those includable as well, > > following a standardized branching and versioning model and the associated > > i18n workflows makes sense as much there as it does for desktop. > > > > If at all the difference is in the distribution channels I think. For > > Linux- based mobile distros there is probably very little difference as > > well. > For the Qt-based mobile apps that are also relevant on the desktop it makes > sense to include them. kdeconnect-android is a bit special in the regard > that it really is an Android-only app. > > > Android can be different though, seeing three possible channels there: > > (1) our self-hosted F-Droid repos, currently for debug nightly builds from > > master, but presumably we could have those as well for release builds from > > the stable branch? > > Having stable releases in our repo is not something I see a use case for if > they are also available from the official F-Droid, which is something I > definitely want to see and am working on. I don't see this as the same thing as the official F-Droid repo, but as a convenient way to get to the stable builds from binary factory (as you describe below), which then are essentially release candidate packages. So ideally that's what we test before tagging/pushing to the production/end user stores. Doing those uploads fully automatic and thus blindly seems a bit risky. > > (2) upstream F-Droid: for this we need actual releases, not binaries, > > quite > > similar to Linux distros > > What we need for this is 1) tagged releases in the git repository and 2) > build scripts in the fdroid repository. I'm working on such a script for > KTrip at the moment. Once this is accepted we can use it as a blueprint for > other apps. AFAIU F-Droid is able to automatically update an app when a git > tag is pushed, so releases wouldn't need action from the release team. The > scripts would need some regular maintainance (checking for failures, > adding/updating dependencies etc), but that would not need to be done by > the release team. > > > (3) Play Store: would probably benefit from (1), if that produces packages > > we can (manually) upload there directly, without needing separate builds > > or > > signing infrastructure > > My idea is that additionally to the nightly builds binary factory also > builds release builds, i.e. from stable branches/tags, compiled in release > mode without debug symbols etc. That's largely what I had in mind for (1), just with the additional small step of putting this into a F-Droid repo as do for the nightly development builds, so it's easier to test those packages. Anyway, tiny detail, the key is building release packages in the first place. > Ideally upload would be done via some > Google Play API, but I don't know if such API exists. > > > So from that perspective I don't see much against including mobile apps. > > However, do we need a way to clearly mark them as such to avoid them being > > distributed on desktop? For Android-only cases like kdeconnect-android > > that's a non-issue, but Kirigami-based mobile apps often build fine on > > desktop too, but might offer a sub-standard user experience there > > (certainly the case for KDE Itinerary). > > I disagree on this. In my opinion those apps should be treated like our > usual desktop apps (part of the release service or not). Mobile > distributions are usually derived from desktop distros in some form so > having them directly availabe would benefit the Linux mobile ecosystem. > Furthermore, the vision of Kirigami is applications that work well on both > mobile and desktop systems and not having them available on "normal" > distros would undermine this vision. In theory I agree. However that doesn't change that the user experience of KDE Itinerary is rather poor on desktop (and IMHO similar for some of the other largely mobile/touch focused Kirigami apps), so I'm looking for ways to manage expectations here. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Add kdeconnect-kde to release service
On Wednesday, 11 December 2019 17:09:11 CET Nicolas Fella wrote: > Hi, > > we would like for KDE Connect to be included in the release service > beginning with the 20.04 release. > > As discussed with Jonathan I've moved the metadata to from extragear/network > to kde/kdeutils. > > I'm unsure about whether kdeconnect-android should move too or stay in > extragear. I assume the release tooling is not prepared for releases to > Google Play. We usually had separate releases for Android since we cannot > align the rollout anyway. Mobile apps in the release service is a good question though, I am interested in that for KDE Itinerary too. I think in general it would be very nice to have those includable as well, following a standardized branching and versioning model and the associated i18n workflows makes sense as much there as it does for desktop. If at all the difference is in the distribution channels I think. For Linux- based mobile distros there is probably very little difference as well. Android can be different though, seeing three possible channels there: (1) our self-hosted F-Droid repos, currently for debug nightly builds from master, but presumably we could have those as well for release builds from the stable branch? (2) upstream F-Droid: for this we need actual releases, not binaries, quite similar to Linux distros (3) Play Store: would probably benefit from (1), if that produces packages we can (manually) upload there directly, without needing separate builds or signing infrastructure Rollout to (2) and (3) does not necessarily be in sync with the release, that's also not the case for many other distributions. So from that perspective I don't see much against including mobile apps. However, do we need a way to clearly mark them as such to avoid them being distributed on desktop? For Android-only cases like kdeconnect-android that's a non-issue, but Kirigami-based mobile apps often build fine on desktop too, but might offer a sub-standard user experience there (certainly the case for KDE Itinerary). Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New Framework Review: KDAV
On Saturday, 9 November 2019 18:45:17 CET Christoph Feck wrote: > Hi Volker, > > On 11/09/19 12:33, Volker Krause wrote: > > 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. > > Could you clarify if the review is about > https://api.kde.org/kdepim/kdav/html/index.html or > https://api.kde.org/kdepim/kdav2/html/index.html ? good point, sorry about forgetting to add the corresponding links :) Code: https://phabricator.kde.org/source/kdav/ API docs: https://api.kde.org/kdepim/kdav/html/index.html Regards, Volker signature.asc Description: This is a digitally signed message part.
New Framework Review: KDAV
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). - 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.
Re: Heads-up: KContacts and KCalendarCore about to move to Frameworks
On Thursday, 19 September 2019 21:40:19 CEST Luigi Toscano wrote:
> Christoph Feck ha scritto:
> > Hello packagers,
> >
> > to minimize disruption caused by the git repo rename, I offered to
> > distribute 19.08.x tarballs with the old name ('kcalcore' instead of
> > 'kcalendarcore').
> >
> > On the other hand, for some packagers that already adjusted it might
> > be convenient to also offer a tarball with its new name.
> >
> > Question:
> >
> > Would it be problematic if the next 19.08.x releases contain both a
> > 'kcalcore' and a 'kcalendarcore' tarball, basically with the same
> > content (except for the directory name)?
>
> If people need the new name, shouldn't they simply use the new Frameworks
> package?
>
> Of course, unless the Frameworks version is not a drop-in replacement
> (Volker?)
It is a drop-in replacement (same library name and ABI), and technically also
with an increasing version number (5.12 to 5.63), unless the 19.08.x version
number was used for the package.
Regards,
Volker
signature.asc
Description: This is a digitally signed message part.
Re: Heads-up: KContacts and KCalendarCore about to move to Frameworks
On Sunday, 15 September 2019 12:19:14 CEST Volker Krause wrote: > Hi, > > as previously discussed here and finally approved during Akademy we will > move KContacts and KCalendarCore from Applications to Frameworks. This > should hopefully cause minimal disruptions as the versions then released > with KF 5.63 are drop-in replacements for the previously releases with > Applications (same ABI, higher version number). > > KCalendarCore will however rename its Git repo in the process to be > consistent (kcalcore -> kcalendarcore). For kdesrc-build users not actively > working on KCalendarCore this should be transparent, otherwise you might > need to adjust the Git remote accordingly. > > I'll inform you once this process has been completed. This has now been executed. Framework releases will start with 5.63.0, Application releases will end after 19.08.x. Regards, Volker signature.asc Description: This is a digitally signed message part.
Heads-up: KContacts and KCalendarCore about to move to Frameworks
Hi, as previously discussed here and finally approved during Akademy we will move KContacts and KCalendarCore from Applications to Frameworks. This should hopefully cause minimal disruptions as the versions then released with KF 5.63 are drop-in replacements for the previously releases with Applications (same ABI, higher version number). KCalendarCore will however rename its Git repo in the process to be consistent (kcalcore -> kcalendarcore). For kdesrc-build users not actively working on KCalendarCore this should be transparent, otherwise you might need to adjust the Git remote accordingly. I'll inform you once this process has been completed. Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: [Semi-Urgent] KDE Applications 18.12 proposed schedule
On Monday, 8 October 2018 22:27:52 CEST Albert Astals Cid wrote: > It's a copy from 18.08 > > https://community.kde.org/Schedules/Applications/18.12_Release_Schedule > > We need to be quick approving this since proposed dependency freeze is next > month. Looks good to me. Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KF5Syndication
On Thursday, 30 August 2018 18:04:56 CEST Christoph Feck wrote: > On 18.08.2018 15:38, Volker Krause wrote: > > The KIO dependency has been refactored away, so [KF5Syndication] is now a > > tier 2 functional framework. > > Any idea why > https://api.kde.org/frameworks/syndication/html/syndication-dependencies.htm > l says it needs KIO? Good question. IIUC kapidox generates this from cmake --graphviz, and that locally shows me no references to KIO (nor does grep'ing the syndication repo). Outdated checkout/dirty build dir on the API docs build machine maybe? Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KF5Syndication
On Monday, 20 August 2018 22:51:44 CEST David Faure wrote: > On samedi 18 août 2018 15:38:48 CEST Volker Krause wrote: > > On Wednesday, 22 April 2015 21:44:05 CEST Daniel Vrátil wrote: > > > Hi all, > > > > > > I'd like to ask for review of another Framework from kdepimlibs: > > > KF5Syndication > > > > > > KF5Syndication is an RSS/Atom parsing library. It also provides API to > > > fetch > > > feeds directly from network. > > > > > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's > > > currently being > > > used only by Akregator. > > > > > > I would like to submit KF5Syndication for the standard 2 week review > > > period, and if everything is OK, then move it to Frameworks. > > > > Now that 18.08 is done let's finally move this forward. > > > > The KIO dependency has been refactored away, so this is now a tier 2 > > functional framework. > > > > Unless there are objections we'd like to move KF5Syndication from PIM to > > KF5 before the 18.12 dependency freeze (ie. in to the KF5 September or > > October releases). > > Works for me. Please request the move and the addition to Frameworks CI so > it shows up on my radar :) This has been done and is reflected in the CI, the dependency meta data and the versioning now. Just the release flag is still missing. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KF5Syndication
On Wednesday, 22 April 2015 21:44:05 CEST Daniel Vrátil wrote: > Hi all, > > I'd like to ask for review of another Framework from kdepimlibs: > KF5Syndication > > KF5Syndication is an RSS/Atom parsing library. It also provides API to > fetch > feeds directly from network. > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's > currently being > used only by Akregator. > > I would like to submit KF5Syndication for the standard 2 week review > period, and if everything is OK, then move it to Frameworks. Now that 18.08 is done let's finally move this forward. The KIO dependency has been refactored away, so this is now a tier 2 functional framework. Unless there are objections we'd like to move KF5Syndication from PIM to KF5 before the 18.12 dependency freeze (ie. in to the KF5 September or October releases). Same procedure as with the KF5Holidays move, it's an ABI-compatible drop-in replacement for what's shipped with 18.08. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Notice of intention to force rewind Akonadi
On Sunday, 1 July 2018 20:49:06 CEST Ben Cooksley wrote: > On Sun, Jul 1, 2018 at 9:31 PM, Volker Krause wrote: > > Rather than letting things escalate for two weeks to this point for what > > is > > essentially a simple one-line change, we probably all should review the > > notification/monitoring workflow. I suspect the main problem was that > > neither the people who broke this nor those who could quickly fix it > > simply weren't aware of the breakage? > > I'm not sure whether email notifications to the mailing list are > suitable to resolve this, but i've now set those up for PIM. Thanks! Email notifications for build failures at least help me notice this faster. Pre-integration CI validation as you are working on should also help a lot with this I think, in particular for the "exotic" platforms (ie. this specific case would have been caught, the change was long enough in review for that). Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Notice of intention to force rewind Akonadi
On Sunday, 1 July 2018 01:16:21 CEST Ben Cooksley wrote: > Hi all, > > We currently have a persistent build failure on Windows for Akonadi, > which in turn is beginning to create maintainability issues for > Extragear projects which have Windows builds. > > Among the projects harmed by this breakage in Akonadi are Alkimia, > Atelier, KMyMoney, Elisa, KDE Connect, Kile, Konversation, KRename, > KStars, KDiagram, Labplot and Okteta. > > As this breakage started occurring approximately 2 weeks ago, we have > now reached the point where an immediate fix is required. Leaving it > in the broken condition we have currently is not an option. > > Therefore to resolve this issue I intend to force rewind Akonadi to > the last successfully built revision, > 28487318a857b9beab33c5e42422fee98944d536, in 48 hours time. Following > this force rewind the Akonadi repository will be locked. This has been fixed. Rather than letting things escalate for two weeks to this point for what is essentially a simple one-line change, we probably all should review the notification/monitoring workflow. I suspect the main problem was that neither the people who broke this nor those who could quickly fix it simply weren't aware of the breakage? Regards, Volker signature.asc Description: This is a digitally signed message part.
Fwd: New module: KItinerary
Hi release team :) As already indicated in the kpkpass discussion, there's a second new module for kde/pim 18.08, kitinerary. It's already moved to kde/pim in the repo structure, and it's in the process of being built on the CI (dependency issues remaining, should be fixed but waiting for the current kf5 mass build to complete now). So there's still the following steps to take care of I think: (1) include it in the release module list (2) there are a dozen or so translated strings that used to be in messageviewer_semantic_plugin.pot and are now in kitinerary.pot. Extraction seems to work as Luigi already reported context errors, not sure if there is anything more to do here to copy the existing translations? Once that's done we can integrate D11932 and make kdepim-addons use this. Thanks! Volker -- Forwarded Message -- Subject: New module: KItinerary Date: Wednesday, 4 April 2018, 19:15:18 CEST From: Volker Krause <vkra...@kde.org> To: kde-...@kde.org Hi, with kpkpass sorted out, let's look at the second new module extracted from the messageview "semantic" plugin in kdepim-addons :) KItinerary contains the travel/reservation data model, data extraction and data augmentation code, for re-use in the corresponding mobile app. Besides extracting the code and turning it into a shared library, the following things have been changed: - the basic data types now are also usable conveniently from C++, not just from QML/Grantlee, at the cost of a bit more boilerplate code. - the extractor engine can now also process pkpass files, next to plain text, html and pdf. - we can now also parse IATA bar coded boarding pass (BCBP) data, ie. the content of the barcodes on boarding passes. If there's no objections I'd like to make this part of the next PIM release too, and port kdepim-addons to use it. Regards, Volker - signature.asc Description: This is a digitally signed message part.
Re: New module: KPkPass
On Thursday, 29 March 2018 22:12:33 CEST Christoph Feck wrote: > On 29.03.2018 13:31, Ben Cooksley wrote: > > On Thu, Mar 29, 2018 at 5:58 AM, Volker Krause <vkra...@kde.org> wrote: > [...] > > >> (2) ??? for the new module to be added to the list of application release > >> modules > >> (3) update module dependencies for kdepim-addons to depend on this once > >> (1) is done > >> (4) once (3) is done, merge the patch that ports kdepim-addons to the > >> external module > > > > Parts 3 and 4 look fine to me, Albert/Christoph are the ones who can > > comment on 2 I think. > > The 18.04 branches are created, so new dependencies for 18.08 can go > into master. I added "kpkpass" to the release modules list; please > inform us of any changes needed. Thanks everyone, I think this is complete now, kdepim-addons is now using this and the CI seems to be ok with that :) Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New module: KPkPass
On Saturday, 24 March 2018 20:54:54 CEST Ben Cooksley wrote: > On Sun, Mar 25, 2018 at 12:15 AM, Volker Krause <vkra...@kde.org> wrote: > > Thanks for the input, but what's the conclusion here now? There's > > arguments > > for and against pretty much all the rules and approaches in here, so I'm a > > bit lost. Can I execute the original proposal? > > Hi Volker, > > I would say the original proposal (of it starting off in KDE PIM then > transferring over to Frameworks when the time comes) should be more > than fine. Great! So how do we get this done? I can think of the following steps: (1) sysadmin ticket for the move from playground (or does this need to go through the kdereview cycle despite being essentially a move from kdepim- addons code?), and for being added to the CI (2) ??? for the new module to be added to the list of application release modules (3) update module dependencies for kdepim-addons to depend on this once (1) is done (4) once (3) is done, merge the patch that ports kdepim-addons to the external module There are no translations in this, so nothing to do in this area I think. Thanks, Volker > While packagers will have some versioning issues to deal with, this is > essentially a solved problem as they've had to deal with it already > for KHolidays) > > Cheers, > Ben > > > On Monday, 19 March 2018 18:04:51 CET Volker Krause wrote: > >> Hi, > >> > >> the below request for adding a new module to KDE PIM for the 18.08 > >> release > >> resulted in some questions about the rules for new modules, as I ended up > >> facing the following conflicting constraints: > >> > >> (1) We do not do "direct-to-frameworks" releases, ie. new modules should > >> be > >> battle-tested elsewhere before moving to KF5. > >> > >> (2) We do not do releases from playground, and following that, no > >> released > >> module can depend on playground modules. > >> > >> (3) Module moves have to be avoided where possible, ie. they should only > >> be > >> done to fix stuff, not as a planned evolution of a module. > >> > >> Do all these rules actually exist, or are some of them myths? :) In > >> particular (3) was new to me. > >> > >> If all three rules are valid, how do I solve the scenario outlined below > >> then? > >> > >> Thanks! > >> Volker > >> > >> On Sunday, 18 March 2018 09:55:27 CET Volker Krause wrote: > >> > Hi, > >> > > >> > in order to make the travel/itinerary code started in kdepim-addons > >> > accessible for the corresponding mobile app too, I'm currently moving > >> > the > >> > shared parts to separate repos/modules. > >> > > >> > The first one ready to go is KPkPass (see kde:kpkpass.git), a library > >> > for > >> > reading Apple Wallet pass files, the de facto standard file format for > >> > mobile boarding passes. No rocket science in there, just parsing the > >> > file > >> > (essentially a zip file containing a JSON file, message catalogs and > >> > image > >> > assets) and making it consumable by Grantlee and QML for display. > >> > > >> > I'd suggest to include this in the next PIM release (after 18.04 > >> > branching > >> > has been done), with the longer term goal to become a tier 2 framework > >> > once > >> > it has been battle-tested as part of one or two PIM releases. This > >> > would > >> > then become a dependency of kdepim-addons, for the pkpass messageviewer > >> > plugin. > >> > > >> > I'm also working on a similar split for the itinerary data model and > >> > extraction code (currently in scratch/vkrause/kitinerary). > >> > > >> > Regards, > >> > Volker signature.asc Description: This is a digitally signed message part.
Re: New module: KPkPass
Thanks for the input, but what's the conclusion here now? There's arguments for and against pretty much all the rules and approaches in here, so I'm a bit lost. Can I execute the original proposal? On Monday, 19 March 2018 18:04:51 CET Volker Krause wrote: > Hi, > > the below request for adding a new module to KDE PIM for the 18.08 release > resulted in some questions about the rules for new modules, as I ended up > facing the following conflicting constraints: > > (1) We do not do "direct-to-frameworks" releases, ie. new modules should be > battle-tested elsewhere before moving to KF5. > > (2) We do not do releases from playground, and following that, no released > module can depend on playground modules. > > (3) Module moves have to be avoided where possible, ie. they should only be > done to fix stuff, not as a planned evolution of a module. > > Do all these rules actually exist, or are some of them myths? :) In > particular (3) was new to me. > > If all three rules are valid, how do I solve the scenario outlined below > then? > > Thanks! > Volker > > On Sunday, 18 March 2018 09:55:27 CET Volker Krause wrote: > > Hi, > > > > in order to make the travel/itinerary code started in kdepim-addons > > accessible for the corresponding mobile app too, I'm currently moving the > > shared parts to separate repos/modules. > > > > The first one ready to go is KPkPass (see kde:kpkpass.git), a library for > > reading Apple Wallet pass files, the de facto standard file format for > > mobile boarding passes. No rocket science in there, just parsing the file > > (essentially a zip file containing a JSON file, message catalogs and image > > assets) and making it consumable by Grantlee and QML for display. > > > > I'd suggest to include this in the next PIM release (after 18.04 branching > > has been done), with the longer term goal to become a tier 2 framework > > once > > it has been battle-tested as part of one or two PIM releases. This would > > then become a dependency of kdepim-addons, for the pkpass messageviewer > > plugin. > > > > I'm also working on a similar split for the itinerary data model and > > extraction code (currently in scratch/vkrause/kitinerary). > > > > Regards, > > Volker signature.asc Description: This is a digitally signed message part.
Re: [kde-release-team] Re: New module: KPkPass
On Tuesday, 20 March 2018 07:20:21 CET Ben Cooksley wrote: > On Tue, Mar 20, 2018 at 10:36 AM, Sandro Knauß <skna...@kde.org> wrote: > > Hey, > > > > On Montag, 19. März 2018 20:26:36 CET Volker Krause wrote: > >> On Monday, 19 March 2018 18:15:49 CET Jonathan Riddell wrote: > >> > On Mon, Mar 19, 2018 at 06:04:51PM +0100, Volker Krause wrote: > >> > > >> > https://community.kde.org/Policies/Application_Lifecycle > >> > > >> > > (1) We do not do "direct-to-frameworks" releases, ie. new modules > >> > > should > >> > > be battle-tested elsewhere before moving to KF5. > >> > > >> > I don't know of that but once in frameworks there's strict ABI > >> > requirements > >> > > >> > so it's usually best to test elsewhere. Self released extragear is > >> > easy > >> > enough. > >> > >> Can Application modules depend on libraries from Extragear releases > >> though? > > > > Why not? Applications can depend on everything external and internal KDE > > including Extragear. > > The only restriction here is that the Extragear component is released > prior to Applications making it's release. > (ie. you shouldn't be dependent on the latest git version) Ok, then Extragear is at least a theoretical path towards Frameworks, while still being immediately useful for Applications. Still feels a bit weird to be "punished" for thinking ahead by having to do manual releases, compared to looking at Frameworks as an afterthought. > Otherwise there is no limitation on Applications -> Extragear (or > Plasma as the case may be) > > Playground on the other hand is quite different - nothing outside > Playground may depend on something in Playground. > > >> > > (2) We do not do releases from playground, and following that, no > >> > > released > >> > > module can depend on playground modules. > >> > > >> > You can make alpha releases from playground, but not beta and final > >> > > >> > > (3) Module moves have to be avoided where possible, ie. they should > >> > > only > >> > > be done to fix stuff, not as a planned evolution of a module. > >> > > >> > No reason why that should be. Moving from Applications to elsewhere > >> > I'd > >> > avoid just because of the version number lowering which annoys > >> > packagers. > >> > >> Right, which excludes the Application -> Frameworks move which is > >> particularly interesting for a number of framework candidates in KDE PIM. > > > > Jonathan only mention, that he would avoid it because of the version > > number > > lowering. It is not a rocket science to bump the epoch number in > > distribution but still work... And at least in Debian we need to test > > with each move between different release cycle, what has changed, if the > > new version breaks older builds. > > > > For me it is more obvious, that if you release a 0.90 in Extragear f.ex. > > and no changes for 6 months and than a new version in Frameworks, from > > what point the API/ABI is stable. Keep in mind Application releases are > > not connected to the internal state of the product. > > > >> Maybe if possible and doesn't feel forced, there can be a name change/ > > > > improvement that may help? > > > > +1 do not use the KF5 namespace before it enters KF5, therefore you have > > the review process to finalize the lib for frameworks. > > Please note that this can create some significant issues with > backwards compatibility during the transition period (for an > applications to frameworks move for instance), as we found out with > Purpose. As it turns out, CMake does not like creating forwarding > targets, particularly on Windows. > > Therefore you might want to start using the KF5 prefix, and port all > applications to that, a little bit before you enter review for > Frameworks. That's what we did for the KHolidays move a while ago, which AFAIK worked quite well, being a drop-in replacement in all aspects. I might not be seeing the full distro picture there though. It's IMHO worth finding the best path here, as with the KDateTime port completed in PIM, there are a few more former kdepimlibs libs (kcalcore, syndication, kmime, kcontacts, etc) lined up to become part of Frameworks, preferably in the least painful way possible :) Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: [kde-release-team] Re: New module: KPkPass
On Monday, 19 March 2018 18:15:49 CET Jonathan Riddell wrote: > On Mon, Mar 19, 2018 at 06:04:51PM +0100, Volker Krause wrote: > > https://community.kde.org/Policies/Application_Lifecycle > > > (1) We do not do "direct-to-frameworks" releases, ie. new modules should > > be battle-tested elsewhere before moving to KF5. > > I don't know of that but once in frameworks there's strict ABI requirements > so it's usually best to test elsewhere. Self released extragear is easy > enough. Can Application modules depend on libraries from Extragear releases though? > > (2) We do not do releases from playground, and following that, no released > > module can depend on playground modules. > > You can make alpha releases from playground, but not beta and final > > > (3) Module moves have to be avoided where possible, ie. they should only > > be done to fix stuff, not as a planned evolution of a module. > > No reason why that should be. Moving from Applications to elsewhere I'd > avoid just because of the version number lowering which annoys packagers. Right, which excludes the Application -> Frameworks move which is particularly interesting for a number of framework candidates in KDE PIM. Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: New module: KPkPass
Hi, the below request for adding a new module to KDE PIM for the 18.08 release resulted in some questions about the rules for new modules, as I ended up facing the following conflicting constraints: (1) We do not do "direct-to-frameworks" releases, ie. new modules should be battle-tested elsewhere before moving to KF5. (2) We do not do releases from playground, and following that, no released module can depend on playground modules. (3) Module moves have to be avoided where possible, ie. they should only be done to fix stuff, not as a planned evolution of a module. Do all these rules actually exist, or are some of them myths? :) In particular (3) was new to me. If all three rules are valid, how do I solve the scenario outlined below then? Thanks! Volker On Sunday, 18 March 2018 09:55:27 CET Volker Krause wrote: > Hi, > > in order to make the travel/itinerary code started in kdepim-addons > accessible for the corresponding mobile app too, I'm currently moving the > shared parts to separate repos/modules. > > The first one ready to go is KPkPass (see kde:kpkpass.git), a library for > reading Apple Wallet pass files, the de facto standard file format for > mobile boarding passes. No rocket science in there, just parsing the file > (essentially a zip file containing a JSON file, message catalogs and image > assets) and making it consumable by Grantlee and QML for display. > > I'd suggest to include this in the next PIM release (after 18.04 branching > has been done), with the longer term goal to become a tier 2 framework once > it has been battle-tested as part of one or two PIM releases. This would > then become a dependency of kdepim-addons, for the pkpass messageviewer > plugin. > > I'm also working on a similar split for the itinerary data model and > extraction code (currently in scratch/vkrause/kitinerary). > > Regards, > Volker signature.asc Description: This is a digitally signed message part.
Re: KHolidays as Framework (redux)
On Sunday, 14 January 2018 12:55:30 CET David Faure wrote: > On dimanche 14 janvier 2018 10:20:38 CET Volker Krause wrote: > > On Tuesday, 6 September 2016 12:03:15 CET Volker Krause wrote: > > > On Friday 01 January 2016 18:24:17 David Faure wrote: > > > > On Thursday 24 December 2015 12:28:13 John Layt wrote: > > > > > Hi, > > > > > > > > > > It's xmas holidays, so it must be time to poke a stick at KHolidays > > > > > again > > > > > for inclusion as a Framework. As far as I am aware there are no > > > > > outstanding > > > > > porting issues with KHolidays and it is ready for review to be > > > > > included > > > > > as > > > > > a Tier 1 Framework in the next possible release. What's the next > > > > > step? > > > > > > > > Please make sure it passes all of the items in this checklist > > > > https://community.kde.org/Frameworks/CreationGuidelines > > > > > > AFAICS this is followed, apart from using the KF5 version number and > > > actually being marked as a framework, which I guess is pending framework > > > approval. > > > > This got lost somehow, any objection to executing the move to frameworks > > for 5.43, say end of this week? > > Go ahead. The necessary metainfo and CMake changes are pushed, the sysadmin ticket for the repo metadata change is T7791. Summary: KHolidays will not be part of the 18.x KDE Application releases anymore, but instead become part of the KDE Frameworks releases with version 5.43. There are no ABI or name changes, just the .so version increases from 5.7 to 5.43 to match the rest of KF5, so the transition should hopefully be hardly noticeable. Side benefit: plasma-workspace no longer depends on a library from KDE Application releases. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KHolidays as Framework (redux)
On Sunday, 14 January 2018 16:50:08 CET Sandro Knauß wrote: > @Volker: Is there a need to rush releasing KHolidays it under frameworks? this request is pending since more than 24 month, not exactly my definition of rushing things ;-) We should do the move reasonably early before the next application release IMHO, so we don't collide with the pre-releases there. Apart from that I don't see any particular timing constraints. > As far I see it, the include mechanism do not change find_package do not > need to change and also the target_libraries do not need to changed also > the API is fixed so far -> no changes in kdepim needed. Exactly, it's all ready to go since two years. > The only thing that > changes is the big bump of the version number and there will be some BIC > cleanup, so there will be BIC breakage with that move. Distributions need > to rebuild everything against the new framework. With only BIC changes > there should be no big issue for distributions to ship a uptodate kdepim > (17.12.X) with a uptodate KDE frameworks. Which BIC changes do you have in mind? The ABI has been stable since August 2015 from what I can see. Regards, Volker > PS: please also inform distributi...@kde.org, if the switch has a fixed > date. > On Sonntag, 14. Januar 2018 15:59:46 CET Allen Winter wrote: > > I don't object to making KHolidays a framework. > > I kinda object to the short timeline. > > > > I wanted to finish up some BIC cleaning. No API changes planned at this > > time. I'll try to hurry. > > > > On Sunday, January 14, 2018 4:20:38 AM EST Volker Krause wrote: > > > On Tuesday, 6 September 2016 12:03:15 CET Volker Krause wrote: > > > > On Friday 01 January 2016 18:24:17 David Faure wrote: > > > > > On Thursday 24 December 2015 12:28:13 John Layt wrote: > > > > > > Hi, > > > > > > > > > > > > It's xmas holidays, so it must be time to poke a stick at > > > > > > KHolidays > > > > > > again > > > > > > for inclusion as a Framework. As far as I am aware there are no > > > > > > outstanding > > > > > > porting issues with KHolidays and it is ready for review to be > > > > > > included > > > > > > as > > > > > > a Tier 1 Framework in the next possible release. What's the next > > > > > > step? > > > > > > > > > > Please make sure it passes all of the items in this checklist > > > > > https://community.kde.org/Frameworks/CreationGuidelines > > > > > > > > AFAICS this is followed, apart from using the KF5 version number and > > > > actually being marked as a framework, which I guess is pending > > > > framework > > > > approval. > > > > > > This got lost somehow, any objection to executing the move to frameworks > > > for 5.43, say end of this week? > > > > > > Regards, > > > Volker signature.asc Description: This is a digitally signed message part.
Re: KHolidays as Framework (redux)
On Tuesday, 6 September 2016 12:03:15 CET Volker Krause wrote: > On Friday 01 January 2016 18:24:17 David Faure wrote: > > On Thursday 24 December 2015 12:28:13 John Layt wrote: > > > Hi, > > > > > > It's xmas holidays, so it must be time to poke a stick at KHolidays > > > again > > > for inclusion as a Framework. As far as I am aware there are no > > > outstanding > > > porting issues with KHolidays and it is ready for review to be included > > > as > > > a Tier 1 Framework in the next possible release. What's the next step? > > > > Please make sure it passes all of the items in this checklist > > https://community.kde.org/Frameworks/CreationGuidelines > > AFAICS this is followed, apart from using the KF5 version number and > actually being marked as a framework, which I guess is pending framework > approval. This got lost somehow, any objection to executing the move to frameworks for 5.43, say end of this week? Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: [Kde-pim] 4.11.0 release and tests
On Monday 05 August 2013 21:54:33 Allen Winter wrote: On Tuesday, August 06, 2013 01:04:08 AM Albert Astals Cid wrote: @people, please keep both lists on the loop. One of the things we agreed we wanted for the 4.11 release was no failing tests on jenkins. We've almost achieved that. http://build.kde.org/view/KDE%20SC%20stable/?auto_refresh=false We have only 8 failing tests, all of them in kdepim-*. Yep, although not entirely surprising considering that's where the majority of all our tests seem to be (1000). That's no excuse of course, just statistics ;) Looking at the fail graphs for kdepim*, you can also see that this plan had some positive effects :) My question to the kdepim people: * Why are those tests failing? Looking at kdepimlibs-stable: TestSuite.kblog-testmetaweblog IIRC that's an online test, probably the remote site changed (happened with a few others from kblog as well), deactivate/expected fail IMHO. TestSuite.Compat-KOrganizer_3.1.ics TestSuite.Compat-KOrganizer_3.2.ics IIRC those were fixed with libical 1.0, right Allen? Looking at kdepim-runtime-stable: TestSuite.kolabconvertertest Broken, wasn't adjusted to the kolab resource rewrite I think, should be deactivated/expected failed. Christian, can you look into fixing this one please? Looking at kdepim-stable: TestSuite.ktimezonecomboboxtest TestSuite.summaryeventtest those fail with ktimezoned error messages here, probably test setup errors? Who could look into that? TestSuite.messageviewer-rendertest TestSuite.messagecomposer-messagefactorytest TestSuite.messagecomposer-maintextjobtest those are in theory valid tests, but fail for technical reasons (crypto setup), non-trivial to fix correctly I think, so temporarily disable/expected fail until someone has time to fix the test harness there, I'd say. My question to release-team and kdepim people: * Should we delay the release until tests are fixed? IMHO that's not necessary. * Should we simply QFAIL/remove the tests since it seems they are not that important? see above, yes. * Should we let them fail and still release? Personally i'd like the tests either fixed or QFailed, this way for 4.11.1 one can go to jenkins, check if everything is green and have a very high level overview that with some luck maybe nothing regressed. yes, makes sense I agree with you. We need 0% failing. Akonadi is at 0% already, can we subscribe kde-pim to Jenkins errors for this one already (and add the rest as soon as we hit 0% there for the first time)? 2 of the kdepimlibs fails are from kcalcore (the TestSuite.Compat.KOrganizer ones) I'm surprised at this. Can someone tell me which version of libical is installed on the jenkins machines? IIRC 1.0, which should explain this. We should QFAIL the kblog test. I can't remember the last time that was working. They use online service and test accounts on these, that's not going to keep working long-term without maintenance. regards, Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 111718: Prevent EntityListCache from causing endless loop
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111718/#review36553 --- Ship it! Looks like it should fix the immediate issue indeed. Thanks! - Volker Krause On July 26, 2013, 12:47 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111718/ --- (Updated July 26, 2013, 12:47 p.m.) Review request for KDEPIM-Libraries and Release Team. Description --- Calling ensureCached() can cause the cache and Monitor to end up in an endless loop. In situation, that there are items 1,2,4,5 and 6 in the cache, calling ensureCached(1,2,3,4,5) will call request(3) and return false. request() internally calls shrinkCache() which removes all fetched items to make sure the cache does not grow indefinitely. After the item 3 is fetched, we end up with cache with only item 3. Monitor will then again call ensureCached(1,2,3,4,5), which will call request(1,2,4,5) which in return calls shrinkCache(), which will remove the item 3 and after fetched is finished the cache only contains items 1,2,4 and 5. This way the cache ends up in an endless loop because it will never contain all items that Monitor requested. This patch prevents shrinkCache() from removing items that are part of the ensureCached() request. I would like to get this patch to 4.11, because it's not that difficult to trigger this bug and in such case you end up with Akonadi resource going nuts (and not processing any further requests) This implementation is still not optimal, because meanwhile the Monitor can call ensureCached(7,8,9), which will cause (1,2,4,5) to be removed from cache anyway, so it can take several tries for EntityListCache to retrieve the entire set (1,2,3,4,5). However now it's guaranteed that at some point the cache will succeed. We can rethink (and maybe remove) the cache when server-side recording is implemented. Diffs - akonadi/entitycache_p.h 5f00917 Diff: http://git.reviewboard.kde.org/r/111718/diff/ Testing --- Thanks, Dan Vrátil ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request: Disable autocompletion-via-nepomuk
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105508/#review15628 --- Ship it! looks good to me. - Volker Krause On July 10, 2012, 4:06 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105508/ --- (Updated July 10, 2012, 4:06 p.m.) Review request for Akonadi, Nepomuk, Release Team, Volker Krause, Till Adam, and Laurent Montel. Description --- Disable autocompletion-via-nepomuk until it is fast and does not block further nepomuk queries (such as the ones run when clicking Send in kmail composer). Without this patch: up to 30 minutes for the composer window to disappear With this patch: immediate. YYMV depending on the size of your nepomuk/virtuoso DB (here it's 3GB, with 400k contacts, autogenerated by the akonadi-nepomuk-feeder). Diffs - libkdepim/addresseelineedit.cpp 5fab510 Diff: http://git.reviewboard.kde.org/r/105508/diff/ Testing --- Thanks, David Faure ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5.0 tagged (1st try of tarballs uploaded)
On Thursday 29 July 2010 14:09:45 Dirk Mueller wrote: Hi, I just finished uploading the first set of KDE 4.5.0 tarballs to stable/4.5.0/src. Please let me know of any blocking issues (JRiddels PyQt 4.7 fix is not yet included I believe). kde-l10n tarballs are still building. I've uploaded the corresponding Akonadi server 1.4.0 tarball to download.akonadi-project.org. regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5.0 tagged (1st try of tarballs uploaded)
On Saturday 31 July 2010 13:16:22 Dima Panov wrote: On Saturday 31 July 2010 21:07:38 Volker Krause wrote: On Thursday 29 July 2010 14:09:45 Dirk Mueller wrote: Hi, I just finished uploading the first set of KDE 4.5.0 tarballs to stable/4.5.0/src. Please let me know of any blocking issues (JRiddels PyQt 4.7 fix is not yet included I believe). kde-l10n tarballs are still building. I've uploaded the corresponding Akonadi server 1.4.0 tarball to download.akonadi-project.org. CMakeLists.txt referenced to doc subdir, but this directory not exist in package sorry about that, this was added by the create_tarball.rb script for some reason. Fixed. regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5 Beta2 (4.4.85) uploaded
On Monday 07 June 2010 10:05:38 Dirk Mueller wrote: Hi, I just finished uploading the first set of tarballs for KDE 4.5 Beta2, which was actually planned to be done end of last week, however I was offline and I didn't have time to do them before leaving due to various private life issues. Lets delay the release until Thursday, I hope this is enough time assuming the current set of tarballs compile+work good (still building them). I've uploaded the corresponding Akonadi server tarball (1.3.85) to download.akonadi-project.org. regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5 Beta2 (4.4.85) uploaded
On Wednesday 09 June 2010 11:12:49 Eric Hameleers wrote: On Wed, 9 Jun 2010, Volker Krause wrote: On Monday 07 June 2010 10:05:38 Dirk Mueller wrote: Hi, I just finished uploading the first set of tarballs for KDE 4.5 Beta2, which was actually planned to be done end of last week, however I was offline and I didn't have time to do them before leaving due to various private life issues. Lets delay the release until Thursday, I hope this is enough time assuming the current set of tarballs compile+work good (still building them). I've uploaded the corresponding Akonadi server tarball (1.3.85) to download.akonadi-project.org. regards Volker Hi Volker Will the addition of 1.3.85 break applications which were linked to akonadi-1.3.80? By now, most packagers will have built their KDE SC 4.4.85 packages against akonadi 1.3.80. Is 1.3.85 a requirement? sorry, I should have mentioned that, using Akonadi 1.3.80 is perfectly fine for KDE 4.4.85, 1.3.85 just contains a few useful fixes but no API or protocol extensions. regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Early Branch.
On Friday 21 May 2010 01:05:00 Sebastian Kügler wrote: Hey, On Thu May 20 2010 19:11:38 Tom Albers wrote: The KDEPIM whishes to branch early, as there are lots of development in KDEPIM, a feature branch is needed. To keep the workflow a bit sane, I suggested that next to KDE-EDU, aslo KDEPIM branches of. All KDEPIM releases will come from that 4.5 branch. Feature development can then continue in trunk. Why not create a work branch for the feature development? I'm actually not too happy with individual modules branching off for bugfixing and using trunk for feature development. We have a freeze for a reason (common rythm of development, reaching acceptable level of quality), and if we need to explain SVN users which trunk branches are frozen, which ones are open for features, and which ones should get the bugfixes, we're making things *really* complicated, as policies are KDE SC-wide, not only apply to a subset of the modules within it. I get it that feature development in trunk is easier, but the main focus is getting our current trunk release ready. That holds true for other modules as well, and it requires a bit of discipline from all or us. Opening up parts of trunk for feature development just sends out the wrong message, and I fear it might have negative effect on the quality of the upcoming release. We're in release mode now, and it's not like that should come as a surprise to anyone. I'm not convinced we should open up trunk for development on features we're not even planning to release inside KDE SC now (i.e. akonadi / kmail mobile). Also, asking for delaying the PIM release because there's not enough time to get it to an acceptable level of quality in time for 4.5.0, and at the same time requesting opening trunk for new features is a bit odd. There are two things happening in KDE PIM right now, stabilizing the desktop applications and completing their port to Akonadi and the development of the KDE PIM mobile applications. Since the latter share the vast majority or their code with the desktop applications, most work done here directly benefits the desktop as well. I do know the business background here, but I would highly appreciate if KDE schedules were taken into account as well. We (KDAB/Intevation) not only take them into account, but also take them very seriously. However, we cannot just stop working on features if KDE freezes since our deadlines unfortunately don't align perfectly. So, we will do that work in a branch in the meantime, like we always have in the past. When hearing about EDU branching early for 4.5 we (KDE PIM) decided to follow that scheme during the meeting last week since it simplifies the branch maintenance considerably and doesn't mess up svn history that much. If it now turns out that this approach is not supported by KDE then we will of course go back to the old one using a development branch. In fact, that's what we will do until this discussion is resolved. I get it that lots of stuff is happening in PIM, and I'm really happy about that, but we need to keep things sane for others as well, and maintain a leveled community. Any objections to this request? If not, Dirk, can you set that up? I'd like to find a better solution for the above problems. We (KDAB/Intevation) have a intermediate deadline for the kdepim mobile work next week Wednesday, so we will go with the work branch until then and hopefully the situation will be resolved by then and I'll adapt our workflow to whatever is decided here. regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 RC2
On Tuesday 19 January 2010 23:35:33 Allen Winter wrote: On Tuesday 19 January 2010 5:05:45 pm Dirk Mueller wrote: Hi, are we ready for KDE 4.4 RC2 tagging? Any known show stoppers? Akonadi bug https://bugs.kde.org/show_bug.cgi?id=219687 was a showstopper. Turns out to be a bug in DBus. Until DBus is fixed or Qt is changed to work around the DBus bug, we have provided a our own workaround in the Akonadi server. I now turn this over to Volker who can fill us in as to what Akonadi server version(s) have this workaround, and how to get the needed code. Etc. there is a new Akonadi server release from a few minutes ago, 1.3.0, which contains the fix and is the currently recommended version for KDE SC 4.4. regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3 RC1 preparations
On Tuesday 23 June 2009 11:11:56 Dirk Mueller wrote: Tonight we plan to tag RC1 according to the schedule. I'd plan to do that tomorrow morning. I need your help in assessing the current status: a) are all dependent projects (akonadi,phonon and various libs) ready for a release? Akonadi is ready to be branched and released. b) do we branch? it was my understanding based on the discussions that we want to branch before this years akademy. I would like to start to branch then to /branches/KDE/4.3 and tag the RC from there. c) announce to kde-cvs-announce when the branching happened and what the next steps are. I would like to avoid branching l10n-kde4 for now, but that means that we have to change the documentation externals again, or hope that nobody touches the documentation after branching. Any comments? d) kdepim tarball splitting is now finalized? regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] kdepim runtime
On Wednesday 17 June 2009 02:16:38 Allen Winter wrote: On Tuesday 16 June 2009 10:48:09 am Allen Winter wrote: On Thursday 07 May 2009 5:47:03 pm Tom Albers wrote: Hi DIrk, * As discussed today, we would like to have a kdepim-runtime tarball, we would like to have it contain the content of /trunk/KDE/kdepim/akonadi. It should be able to compile stand alone and only contains the stuff that is a runtime dependency for akonadi application. That way for example Mailody can depend on that package instead of depending on the whole of kdepim. We should decide about the renaming kdepim/akonadi to kdepim/runtime/akonadi or we could create a kdepim-runtime next to kdepim as top level folder. I really don't care about what solution will be taken as I can not oversee the build consequences at all. So I think the experts should give their opinion about that. I hope we can do this for the 4.3 releases. Does not have to be for the tagged beta of course, althought that would be nice for the packagers to adapt to the change. PIMSters, How are we doing on this? The RC1 tagging is coming in about 1 week. We need a complete separation of kdepim-runtime code in place before then. Last I heard, there were still 2 blockers of stuff in kdepim/akonadi that was dependent on other areas in kdepim. Please advise on the status of this project. After talking to Christophe, Volker, and Thomas today, we have the following plan: 1) put copies of the 2 blocker classes from kdepim/libkdepim into kdepim/akonadi. they will be clearly marked as copies that need to die and be reborn in kdepimlibs. This should allow all of akonadi to build without any other parts of kdepim. 2) create 2 top-level subdirs: runtime and apps (sound familiar?) Move akonadi, strigi-analyzers (and maybe kresources and plugins) into the new kdepim/runtime. Move everything else into kdepim/apps I suggest to just rename akonadi to runtime then, we don't need the extra level of directories there. If possible packaging-wise I would also suggest to omit the apps directory and leave that stuff on top-level, otherwise branch-maintenance will be a nightmare. Keep in mind that we have half a dozen active branches with merge tracking to trunk! At least wait until trunk is open again, then we can merge the work branches (soc, akonadi ports) first, leaving only the 4.x and enterprise branches. Regarding moving kresources and plugins: None of those are currently movable due to their dependencies (plugins depends on KMail, kresources at least on libkdepim). So, I suggest we ignore those for now, kresource will eventually go away anyway. 3) kdepim/CMakeLists.txt will basically become a 2-liner: add_subdirectory(runtime) add_subdirectory(apps) regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3 Beta1 packages (4.2.85)
On Thursday 07 May 2009 16:58:36 Tom Albers wrote: At Thursday 07 May 2009 16:18, you wrote: At Thursday 07 May 2009 16:12, you wrote: Hi, I've generated a first set of KDE 4.3 beta1 tarballs last night based on the 4.2.85 tag that I created before, and it doesn't look good, a lot of modules fails to compile for me, and I'm still busy figuring out how to fix them . the failures I see are essentially equivalent to what is on http://ktown.kde.org/~dirk/dashboard/ Please help to get this resolved, otherwise it doesn't make sense to upload the beta1 tarballs. Thanks, Dirk There's also the problem that the tagging was a day later than expected, and exactly that day someone made a protocol change in Akonadi. So although it will compile with the 1.1.85 akonadi tarball, it won't work. I'll fix it as soon as I get a reply on this issue on the kdepim mailinglist and I find some time... that's mainly my fault, I did approve this commit without carefully enough checking if the tagging already happend (I was slightly disconnected due to travel). I'm very sorry that kdepim again broke the tag :-( Pimlibs tag has been changed to not include that commit. So the 1.1.85 akonadi tarball *can* be used with the kdepimlibs tarball Dirk will provide. Thanks, that was the solution I would have suggested as well. regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: branches/KDE/4.2/kdepimlibs/kresources
On Wednesday 29 April 2009 09:54:00 André Wöbbeking wrote: SVN commit 960819 by woebbe: Don't leak KConfig in self(). good catch, but... Now only the factories are leaked :-( M +2 -2 factory.cpp --- branches/KDE/4.2/kdepimlibs/kresources/factory.cpp #960818:960819 @@ -73,8 +73,8 @@ mSelves-insert( resourceFamily, factory ); // Akonadi migration -KConfig *config = new KConfig( kres-migratorrc ); -KConfigGroup migrationCfg( config, Migration ); +const KConfig config( kres-migratorrc ); ... the const here makes the following KConfigGroup read-only and assert as soon as we write to it. The result is that every user of the KResource API (most of kdepim, but also eg. kopete, konversation and krunner) will crash immediately on starting for new users. Rather bad as this apparently went into 4.2.3. The fix is easy (remove the const) and will be applied to trunk and the 4.2 branch shortly and should go into 4.2.3 if possible. +KConfigGroup migrationCfg( config, Migration ); const bool enabled = migrationCfg.readEntry( Enabled, false ); const bool setupClientBrige = migrationCfg.readEntry( SetupClientBridge, true ); const int currentVersion = migrationCfg.readEntry( Version- + resourceFamily, 0 ); regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1.0 tarballs (try #1) update
On Sunday 27 July 2008 10:23:43 Mark Davies wrote: On Sunday 27 July 2008 19:01:39 Tom Albers wrote: Akonadi is available @ http://download.akonadi-project.org/ Thanks, although I'll note that http://download.akonadi-project.org/akonadi-1.0.0.tar.bz2 doesn't work as a URL, you have to go to http://akonadi.omat.nl/akonadi-1.0.0.tar.bz2 this should work now. regards Volker signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
