add OARS rating and some release to appdata file
AbandonedPublic

Authored by mgallien on May 16 2019, 7:34 PM.

Details

Reviewers
aacid
mlaurent
yurchor
Group Reviewers
KDE Games
Summary

should fix the errors reported by flathub appdata validator

Test Plan

appdata test is OK

Diff Detail

Repository
R388 Kapman
Branch
Applications/19.04
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 11882
Build 11900: arc lint + arc unit
mgallien created this revision.May 16 2019, 7:34 PM
Restricted Application added a reviewer: KDE Games. · View Herald TranscriptMay 16 2019, 7:35 PM
Restricted Application added a subscriber: kde-games-devel. · View Herald Transcript
mgallien requested review of this revision.May 16 2019, 7:35 PM
yurchor added inline comments.May 16 2019, 7:47 PM
org.kde.kapman.appdata.xml
149

I'm afraid that this change will immediately trigger a "build warning" in our build system. Similar to this for Killbots:

https://build.kde.org/job/Applications/job/killbots/job/kf5-qt5%20SUSEQt5.10/25/testReport/(root)/projectroot/appstreamtest/

Do these "fixes" really solve something?

Thanks in advance for your answers.

mgallien added inline comments.May 16 2019, 7:53 PM
org.kde.kapman.appdata.xml
149

It aims at fixing this kind of errors: https://flathub.org/builds/#/builders/8/builds/414 .
It would probably be a good idea to fix the validation to no longer report such a warning.

aacid added inline comments.May 16 2019, 7:55 PM
org.kde.kapman.appdata.xml
149

funny thing is that afaik the same app is used in both places, just different versions of it that have different constraints.

156

the problem with this is that it's unmaintainable without proper automation at the KDE Applications release engineering level.

mgallien added inline comments.May 16 2019, 8:03 PM
org.kde.kapman.appdata.xml
156

There is this https://invent.kde.org/jriddell/appstream-metainfo-release-update . It should be possible to integrate it but I do not know where.

aacid added inline comments.May 16 2019, 8:37 PM
org.kde.kapman.appdata.xml
156

Yes, that's being discussed in 3 or four different places
https://phabricator.kde.org/T10812
https://phabricator.kde.org/D21091
https://phabricator.kde.org/T10755

I *think* a general welcome solution would be extract the part of add-bugzilla-versions/add-versions.py that parses the cmake version out of to some common .py file that could them be used to somehow feed appstream-metainfo-release-update from https://cgit.kde.org/sysadmin/release-tools.git/tree/increase_repos_version.sh

It's just that noone seems to have really pushed for it.

I have identified at least several cases and related actions:

  • some applications already have a version indicated in the cmake project command. They are automatically managed through KDE_APPLICATIONS_... variables. A call to add the version also in the appdata file would fill in the release XML tags ;
  • some applications already have a version indicated in the cmake project command. They are manually managed through. When updating the KDE_APPLICATIONS_... variables, the specified version can be extracted and pushed to a new release XML tag ;
  • some applications do not have a version set in cmake project command. Should I add one and see if KDE_APPLICATIONS_... variables can be used. This would be the same as the first case ;
  • To allow use of empty content_rating tags, the cmake appdata test should use the same validator than flathub.

I plan to start with the last case as it seems easier given my current skills. I would greatly appreciate any hints on how best handle applications without versions in their cmake project command.

Yeah the problem is that this will drift out of date over time. We need a way of populating these automatically, end ensuring that the version number in the tag is the actual one used by the app itself. I think everyone is in favor of it though. Maybe for @jriddell who's currently working on similar things?

See also T10971: KDE Applications release scripts should add version number to appstream files which is probably where we should centralize the discussion.

mgallien abandoned this revision.Jan 26 2020, 9:00 PM