Re: AppStream Metadata with our releases

[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.

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.

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: KDE Gear projects with failing CI (master) (19 March 2024)

[Bart De Vries]

On 21/03/2024 23:40, Julius Künzel wrote:
Am 20. März 2024 um 06:02 schrieb "Justin Zobel" >:


On 20/3/24 08:55, Albert Astals Cid wrote:

 [...]

kasts - NEW

*
https://invent.kde.org/multimedia/kasts/-/pipelines/637451

* flatpak fails

* craft_windows_qt6_mingw64 fails


Fixed the flatpak job, it just needed to be re-run as there was an
issue downloading the VLC tar.

 [...]

Kasts Craft Windows build seems to have fixed itself. (BTW why does 
Kasts use MinGW Craft jobs while it seems to work with MSVC given that 
it has a Windows CI job which is MSVC based? MinGW should only be used 
if really needed)


It didn't actually fix itself: Hannah solved a broken MinGW lua install, 
which fixed the Kasts CD build.


NB: Kasts has the MinGW job activated in preparation for switching the 
audio/video backend to MPV, which is only available on MinGW. See branch 
'work/mpv-backend'.
At the moment that branch is merged, the regular MSVC CI job will (have 
to) be deactivated.


Bart