Re: AppStream Metadata with our releases
Sensing from my phone so sorry for the html email On Sat, Mar 23, 2024, at 9:06 PM, Julius Künzel wrote: > 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? I see that Volker do add release information for Itinerary on every release and I also try to do that for neochat, tokodon and a few other apps. > > > > > 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? +1
Re: AppStream Metadata with our releases
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 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: Markdown Tools - Request for a Sponsor
Hello. On 23.03.2024 14:26, Benson Muite wrote: Markdown is very popular, but in many applications it is extended in non standard ways. Org mode is another readable markup language, but unlike Asciidoc it seems to have C++ libraries: https://github.com/mirkoboehm/OrgModeParser This seems not fully-featured. https://github.com/haxscramper/haxorg I'm unable to build it even. Most org mode users use Emacs, but giving an alternative editor may be useful.
Re: Markdown Tools - Request for a Sponsor
On 17/03/2024 20.40, Igor Mironchik wrote: > > On 17.03.2024 18:54, Benson Muite wrote: >>> Does it have a set of tests? >>> >>> I don't know how complicated AsciiDoc format is, maybe it's simpler of >>> Markdown? >>> >> It is more complicated than Markdown as it is more complete and allows >> for some self-consistent extensibility. > > More complete is not more complex for parsing... In Markdown a lot of > complexes. But I will think on it. > >> There is a lack of tools for AsciiDoc, but would not make that the >> primary concern. If it can be done, it would be nice, but it seems >> challenging. > > > The problem is that I see users of AsciiDoc even less of Markdown... > Markdown is very popular, but in many applications it is extended in non standard ways. Org mode is another readable markup language, but unlike Asciidoc it seems to have C++ libraries: https://github.com/mirkoboehm/OrgModeParser https://github.com/haxscramper/haxorg Most org mode users use Emacs, but giving an alternative editor may be useful.
