search

flathub-infra / flatpak-builder-lint

A linter for flatpak-builder manifests
MIT License
50 stars 133 forks source link

developer_name check inconsistencies #273

Closed anarcat closed 9 months ago

anarcat commented 9 months ago

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 https://github.com/dweymouth/supersonic/pull/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 commented 9 months ago

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

The doc will be updated soon https://github.com/flathub-infra/documentation/pull/204

Flathub does not support the developer tag, that is blocked by the port to libappstream that will happen soon see https://github.com/flathub/flathub/issues/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 https://github.com/flathub-infra/documentation/pull/203

dginovker commented 9 months ago

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

bbhtt commented 9 months ago

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 commented 9 months ago

Docs are up now

Let's close this https://github.com/flathub-infra/flatpak-builder-lint/issues/274 will track changing the check in linter post libappstream migration whenever that happens.

dreua commented 8 months ago

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

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

It had been a warning since last year https://github.com/flathub-infra/flatpak-builder-lint/commit/5e3e3bc20ceedfbbb10287410c63c384a19c4e92

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 commented 8 months ago

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:

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:

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 commented 8 months ago

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 commented 8 months ago

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.