Re: KDE Frameworks with failing CI (kf5) (24 March 2024)
El dilluns, 25 de març de 2024, a les 18:03:27 (CET), Volker Krause va escriure: > On Sonntag, 24. März 2024 23:14:12 CET Albert Astals Cid wrote: > > Please work on fixing them, otherwise i will remove the failing CI jobs on > > their 4th failing week, it is very important that CI is passing for > > multiple reasons. > > > > Bad news: 2 repositories have started failing > > > > kirigami - NEW > > > > * https://invent.kde.org/frameworks/kirigami/-/jobs/1679118 > > > > * Android build fails > > > >* Something qt related needs a rebuild? > > Yep, looks like a version mix due to the patch collection rebase. But why has this happened? I mean how is it that some Qt has different than some other Qt? Was there a rebuild of Android Qt while i was doing the rebase? If I understand that right there's a QtSvg is 5.15.13 but QtWidgets is only 5.15.12? > I'm wondering how we want to proceed here longer term, as this will continue > to need active maintenance while most of our Android apps have meanwhile > moved to Qt 6. > > Pin the Qt version in Craft to a fixed revision? Drop Android KF5 CI builds? > Find volunteers to do the work of keeping this running/working? If we're saying Kirigami works on Android ideally we should keep a CI. Cheers, Albert > > Regards, > Volker
Re: AppStream Metadata with our releases
El dilluns, 25 de març de 2024, a les 19:37:07 (CET), Volker Krause va escriure: > On Freitag, 22. März 2024 00:37:00 CET Julius Künzel wrote: > > AppStream metadata are consumed by app stores like Flathub, Snapcraft, > > Discover, our scripts to submit apps to the Microsoft Store and last but > > not least by apps.kde.org [2]. > > Same for generating the package metadata on Android, both for our F-Droid > repositories and the Google Play store. > > > - Also it would be convenient to add noteworthy changes to the metadata > > together with the related code change. However at the moment for KDE Gear > > the release is usually only added to the metadata a few days before > > tagging. Would it be possible to add the next minor release to the release > > branch right after the current one has been released and the next major > > release to master ones the upcoming version has been branched? > > At least in the past the appstream validator complained about releases dated > (too far) into the future, but that doesn't seem to be a problem anymore > fortunately. > > As Itinerary was mentioned, the process there currently is to run David's KF > changelog script over all repositories in Itinerary's dependency chain and > take the top 5 or so most visible/important changes (which here are > actually often from other repositories). The commit adding the release to > appstream is my reminder for that currently, but there's other ways to do > that, so for Itinerary the proposed change wouldn't make much of a > difference either way. This brings an interesting point, it would seem that the right time to add the release description is at the end of the release cycle when you know all the changes, not when a particular commit is made. Because if there's 400 changes, you will only want to have the 5 more important changes in the description, but if there's only 5 changes, you may as well add them all. Cheers, Albert > > Regards, > Volker
Re: AppStream Metadata with our releases
El dissabte, 23 de març de 2024, a les 21:06:46 (CET), Julius Künzel va escriure: > 22.03.2024 17:22:33 Albert Astals Cid : > > El divendres, 22 de març de 2024, a les 0:37:00 (CET), Julius Künzel va > > > > escriure: > >> Hi! > >> > >> (This mail goes to multiple lists, please reply to kde-devel) > >> > >> With Flathub beeing more strict on its AppStream metadata guidlines [1] > >> there is yet another spotlight on AppStream metadata. > >> > >> AppStream metadata are consumed by app stores like Flathub, Snapcraft, > >> Discover, our scripts to submit apps to the Microsoft Store and last but > >> not least by apps.kde.org [2]. > >> > >> For release info in particular the quality guidelines say: "Make sure all > >> your releases have release notes, even minor ones." [3] As I think this > >> makes perfectly sense, I like to propose two things that seem straight > >> forward to me: > >> > >> - We should not remove older releases from the AppStream data as already > >> suggested by Carl in a merge request [4]. > >> > >> - Also it would be convenient to add noteworthy changes to the metadata > >> together with the related code change. However at the moment for KDE Gear > >> the release is usually only added to the metadata a few days before > >> tagging. Would it be possible to add the next minor release to the > >> release > >> branch right after the current one has been released and the next major > >> release to master ones the upcoming version has been branched? > >> > >> I belive this makes it easier for developers to contribute to the release > >> meta info and I hope it hence raises motivation to do so. > > > > My pessimistic opinion is that no one is going to add release notes, we've > > tried multiple ways to do it, even just asking people to add a keyword to > > the commit log if that commit log was release news worthy and no one did > > it past the first few weeks/months. > > Well, that might happen, but we don't know if we don't try... And as I don't > see this causing any extra work and (yet) can't see any downsides, it is > even worth it if it helps just a single app or developer, no? It is some extra work (not a lot, but some). You're asking for the workflow of creating to be releases to be changed by creating the entry in the file earlier, that alone is a bit of work, but it has several other consequences: * https://apps.kde.org/okular/ shows releases from the appstream file (i think) meaning that the code should learn to ignore releases in the future. Arguably we would need also now, but given the data is added just a few days before the actual release i think users can understand "this release will happen soon)" compared to a thing one month in the future * What happens if we have to change the release date or release version number (hasn't happened in a good while, but wouldn't be a bad thing to prepare for it). We would need to update the string or date of an existing entry, as far as I know we don't have tooling for that (because we only add the data to the file when we're almost sure abiyt it). Would you be able to work on fixing those two? (make the apps.kde.org page not show future releases and have a script in release-tools to change the date/ version-number of a release?) Cheers, Albert > > It seems appstream has finally added the support (or maybe was > > there > > forever?), so my suggestion is that we just add an release+url entry > > pointing to > > https://kde.org/announcements/gear/x.y.z/ > > > > This way we don't have to do the work twice and has the added bonus of > > already translatable. > > This is a nice suggestion too! > However, I don't think this conflicts with my suggestion as the text in the > appstream should usually be just a short summary of the highlights. So > let's do both? > > Only "problem" is that maybe if we get too many people contributing their > > release news the announcements gets too long, but that'd be a nice problem > > to have. > > > > Cheers, > > Albert > > > >> I am happy to hear your opionions, thoughts and concerns! > >> > >> Cheers, > >> Julius > >> > >> [1] https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines > >> [2] https://apps.kde.org/ > >> [3] > >> https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/quality > >> -g > >> uidelines/#release-notes [4] > >> https://invent.kde.org/sysadmin/appstream-metainfo-release-update/-/merge > >> _r > >> equests/6 > >> > >> Julius Künzel > >> Volunteer KDE Developer, mainly hacking Kdenlive > >> KDE GitLab: www.invent.kde.org/jlskuz https://invent.kde.org/jlskuz > >> Matrix: @jlskuz:kde.org https://go.kde.org/matrix/#/@jlskuz:kde.org
Re: AppStream Metadata with our releases
On Freitag, 22. März 2024 00:37:00 CET Julius Künzel wrote: > AppStream metadata are consumed by app stores like Flathub, Snapcraft, > Discover, our scripts to submit apps to the Microsoft Store and last but > not least by apps.kde.org [2]. Same for generating the package metadata on Android, both for our F-Droid repositories and the Google Play store. > - Also it would be convenient to add noteworthy changes to the metadata > together with the related code change. However at the moment for KDE Gear > the release is usually only added to the metadata a few days before > tagging. Would it be possible to add the next minor release to the release > branch right after the current one has been released and the next major > release to master ones the upcoming version has been branched? At least in the past the appstream validator complained about releases dated (too far) into the future, but that doesn't seem to be a problem anymore fortunately. As Itinerary was mentioned, the process there currently is to run David's KF changelog script over all repositories in Itinerary's dependency chain and take the top 5 or so most visible/important changes (which here are actually often from other repositories). The commit adding the release to appstream is my reminder for that currently, but there's other ways to do that, so for Itinerary the proposed change wouldn't make much of a difference either way. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (kf5) (24 March 2024)
On Sonntag, 24. März 2024 23:14:12 CET Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for multiple > reasons. > > Bad news: 2 repositories have started failing > > kirigami - NEW > * https://invent.kde.org/frameworks/kirigami/-/jobs/1679118 > * Android build fails >* Something qt related needs a rebuild? Yep, looks like a version mix due to the patch collection rebase. I'm wondering how we want to proceed here longer term, as this will continue to need active maintenance while most of our Android apps have meanwhile moved to Qt 6. Pin the Qt version in Craft to a fixed revision? Drop Android KF5 CI builds? Find volunteers to do the work of keeping this running/working? Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Automation & Systematization sprint in Berlin in late April
Sorry for the crazily delayed response. I'm digging out from under the megarelease email bomb. On 3/3/24 16:23, Albert Astals Cid wrote: What's the plan for travel support requests? Should we start filing requests at https://reimbursements.kde.org ? Yep. The event is https://reimbursements.kde.org/events/187 Should requests include travel and hosting or hosting will be booked centrally? Include both travel and accommodations; folks are on their own for both. If you're planning to attend, please add yourself to https://community.kde.org/Sprints/Goals/2024. Thanks everyone! Nate
