search

AppImage / appimage.github.io

Given an URL to an AppImage, the GitHub action in this project inspects the AppImage and puts it into a community-maintained catalog
https://appimage.github.io/
Other
297 stars 547 forks source link

[Enhancement Suggestion] Rename 'Author' field to 'AppImage Creator' on AppImageHub #322

Open KurtPfeifle opened 6 years ago

KurtPfeifle commented 6 years ago

On AppImageHub the overview table

On the page for the individual applications, the 'Author' named isn't necessarily the developer of the application, but only the packager of the AppImage.

Example screenshot:

Of course, I'm not the author of HTMLDOC -- that's Mike Sweet. I only started package the thing, in the hope that Mike will consider to merge a pull request of mine once I'm satisfied with the quality of this AppImage.

Therefore I suggest to rename that field to 'AppImage Creator' or 'AppImage Packager'. At the same time add another field for 'Software Author' or similar and populate it (if available) with the contents of the "<developer_name>....</developer_name>" tag from the AppStream .appdata.xml

probonopd commented 6 years ago

Well, the idea is that AppImage is a tool for upstream authors to distribute their applications directly to end users, without a separate "packager" entity in between the author and the user.

In cases where you have written scripts that generate AppImages, I would hope that you could send (and get accepted) your pull requests by the official authors of the applications, in which case they would distibrute official AppImages...

On the page for the individual applications, the 'Author' named isn't necessarily the developer of the application, but only the packager of the AppImage.

For official, upstream-provided AppImages (which we want to list here) the two are identical.

KurtPfeifle commented 6 years ago

*harrumph...* So what about Emacs and XChat? *ahemm...* (And there are probably more.)

Of course I want to get the ones I currently have there to become official ones.

However, let's face it: for quite a while to come there will ALWAYS be some which are in such an "intermediate" stage, and in some cases this may last longer than a few weeks. So you want to remove all these from the Hub? That would not exactly help the cause to expose working AppImages to whoever is interested in them, and would not motivate upstream developers to embrace them. In such transitional cases it would be better to have these two roles clearly identified.

Of course I support the goal to motivate the upstream developers to provide "official" AppImages. Maybe consider a clearly separated section of the Hub table which marks unofficial ones as such and explains that they are there for "demo" purposes or for other reasons (maybe, because the packager just wants the AppImage, but upstream isn't interested)?

In any case: my request to extract the relevant info from the "...." tag of the AppStream metadata still stands...

probonopd commented 6 years ago

Well, I have hundreds of "Demo" ones on Bintray, but I don't want to list them here for exactly this reason - they are not officially supported or endorsed by their original authors. So the thing to do is follow up with the original authors and motivate them to provide official AppImages.