developer_name check inconsistencies

[anarcat]

I've had a flatpak build just failed because we're missing a <developer_name> tag in the appstream file, supposedly:

https://buildbot.flathub.org/#/builders/19/builds/11959

(from dweymouth/supersonic#324).

It links to this documentation:

https://docs.flathub.org/docs/for-app-authors/linter/

... which i guess specifically means:

https://docs.flathub.org/docs/for-app-authors/linter/#appstream-missing-developer-name

... but that's under the "Linter warnings" section. But it was raised as en error in the build:

flatpak run --command=flatpak-builder-lint org.flatpak.Builder --exceptions repo repo
 in dir /srv/buildbot/worker/build-x86_64-1/build (timeout 1200 secs)
 watching logfiles {}
 argv: b'flatpak run --command=flatpak-builder-lint org.flatpak.Builder --exceptions repo repo'
 using PTY: False
{
    "errors": [
        "appstream-missing-developer-name"
    ],
    "warnings": [
        "appstream-summary-too-long",
        "appstream-screenshot-missing-caption"
    ]
}
Please consult the documentation at https://docs.flathub.org/docs/for-app-authors/linter
program finished with exit code 1
elapsedTime=54.274905

So that's the first problem. The second is it seems strange to recommend <developer_name/> considering it's actually deprecated upstream - shouldn't the linter recommend <developer name=""/> tag instead?

[bbhtt]

Yea it was promoted to error last night just before I went to bed 😅

The doc will be updated soon flathub-infra/documentation#204

Flathub does not support the developer tag, that is blocked by the port to libappstream that will happen soon see flathub/flathub#4882 for context. A lot of things broke on distro side and Flathub side when migration was tried last time.

This PR has the docs for appdata guidelines Flathub needs flathub-infra/documentation#203

[dginovker]

Would you recommend going back to developer_name for now or wait it out?

[bbhtt]

Yes please use developer_name for now like the linter page says.

There's no definite timeline on the libappstream migration other than some time this year.

[bbhtt]

Docs are up now

• https://docs.flathub.org/docs/for-app-authors/linter/#appstream-missing-developer-name is an error now
• I've refactored the appdata guidelines page to include the all the things needed for Flathub and to pass validation https://docs.flathub.org/docs/for-app-authors/appdata-guidelines/#name-summary-and-developer-name

Let's close this #274 will track changing the check in linter post libappstream migration whenever that happens.

[dreua]

Stuff like this really frustrates me as a developer / maintainer:

• This change prevents me to do dependency updates for our app. I feel responsible for updating the bundled libraries with bugfixes and maybe even security fixes.
• I'm now supposed to add an already deprecated tag to the appdata file?! Or patch it specifically for flathub? Update: Resolved 2 weeks later
• I didn't see any announcement or warnings regarding this before.
• Coming here I just see "it was promoted" but no reasoning. Any pointers towards why this decision was made?

Would it be possible to demote this back to a warning?

(This is in no way meant as a criticism against @bbhtt but rather how stuff is handled around here in general. I'm still very grateful for your help fixing the python import paths btw.)

[okias]

as @dreua this is dev unfriendly way of handling stuff.

Could we ask for keeping things as they we're (no check) and NOT introducing (freshly, right, I get it) deprecated tag?

This will create much more confusion in next days...

edit: of course I read why it's done and I saw updated docs... now, after wondering what happenend and reading about developer X developer_name and 15 minutes of searching + looking at non-existent examples of <developer>

[bbhtt]

The migration happened this Thursday. Both developer with name child tag and older developer_name tag should be supported now.

The docs will be updated soon.

[dreua]

Thanks for the update @bbhtt ! The other three points from my previous post as well the the question to demote it back to warning still stands.

I'd really appreciate a few month prior announcement for breaking changes like this to allow developers to update their apps and release a new version. (I think Fedora has some good processes in place to manage changes like this if you want an example.)

I guess I'll just stop updating PDF Arranger on Flathub and recommending Flathub as as source for apps for now.

[bbhtt]

It had been a warning since last year 5e3e3bc

Warnings are expected to be solved, otherwise there's no point of raising them.

Reality is no one cares about warnings, and it's impossible to contact upstream and maintainers of all ~2500 applications on Flathub and expect that everyone solves it in time so that a change can be deployed.

Then there would be no changes possible and we would be waiting indefinitely.

[dreua]

I think this is an issue of communication and visibility of these warning. I have really never seen the warning and I have been to the build system multiple times for other reasons. The way it is currently designed the warnings are hidden from maintainers. Some ideas to improve the situation:

• Display those warnings prominently at least in the build system
• Make flathub bot post those warnings to the PR (it already posts failure/success so part of that is already in place)
• Automatically raise Github issues for those warnings

I realize that there will still be maintainers who don't care but the way it currently works frustrates even the developers who do care and they will switch to the former group sooner or later in order to protect themselves from more frustration. The developers who don't care, however, shouldn't complain given a visible warning and enough time to adapt. (Might be a good idea to add a deadline to the warning / change notification.)

and it's impossible to contact upstream and maintainers of all ~2500 applications on Flathub and expect that everyone solves it in time so that a change can be deployed.

It absolutely is possible and has been done for years in other projects, two possibilities that instantly come to mind:

• A low traffic mailing list for announcements like this
• A low traffic Github repository / issue tracker where developers can subscribe but only a limited set of people can post and therefore create notifications.

Asking developers/maintainers to subscribe to those can be mandatory or at least strongly recommended for new apps. Earlier might have been better but now is still a good time to establish such a communication channel.

Then there would be no changes possible and we would be waiting indefinitely.

I 100 % agree that this outcome is not what anyone wants but your argumentation leading to this conclusion is flawed. I already gave the Fedora project as a counterexample.

[bbhtt]

Some of your points solve the reaching out aspect, but still doesn't solve the aspect of everyone subscribing to such lists, seeing the announcement, doing the changes in time etc. which goes back to my point.

Anyways, all of this is going to require infra work that I can't do alone. I just volunteer my free time for flatpak and flathub as is rest of the other people working on Flathub.

I talked with the rest of the people, and there is going to be a blog post about the linter or something like that soonish.

Will look into/talk more about how new checks made in linter can be announced.

If it's going to be announced it's probably going to be one of Flathub discourse, github issues on the repo or emails to maintainers. Flathub/Flatpak moved away from mailing lists some time ago.

The last two are difficult right now because the linter isn't hooked to the website's email or account system and can only happen once a build has already failed so not really useful without the first.

There's also the issue of being too spammy with opening issues because it has to run and notify on test builds to be useful.

[bbhtt]

Also some of the errors from linter don't come from us. They are from appstreamcli validate https://github.com/ximion/appstream

Flathub has no control over what appstreamcli shows errors on or what spec changes they decide to make (like developer name change).

We just show the result of the validation and deal with the fallout from that.