[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: AppStream Metadata with our releases
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2024-03-25 22:23:01
Message-ID: 4863078.Dvduau7jar () xps15
[Download RAW message or body]

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 <aacid@kde.org>:
> > 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 <url/> 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




[prev in list] [next in list] [prev in thread] [next in thread]