Let's write metadata about add-ons

[Jiri Eischmann]

Hi,
due to previous efforts we have a pretty good appdata coverage of apps themselves, but
add-ons (plugins, extensions,...) lag far behind. There are dozens of useful GUI app
add-ons in Fedora repositories which don't have metadata files and are not exposed to
users in GNOME Software. Let's focus on them.

The goal of this iniciative is to have a metadata file for every useful add-on (for a GUI
app) that is in Fedora repositories, so that those add-ons appear in app profiles in
Software and are easily discoverable and installable for users.

For more information visit https://fedoraproject.org/wiki/Workstation/AddonAppdata

Jiri

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/21/2015 05:36 AM, Jiri Eischmann wrote:
>  Hi, due to previous efforts we have a pretty good appdata coverage 
>  of apps themselves, but add-ons (plugins, extensions,...) lag far 
>  behind. There are dozens of useful GUI app add-ons in Fedora 
>  repositories which don't have metadata files and are not exposed to
>  users in GNOME Software. Let's focus on them.
>  
>  The goal of this iniciative is to have a metadata file for every 
>  useful add-on (for a GUI app) that is in Fedora repositories, so 
>  that those add-ons appear in app profiles in Software and are 
>  easily discoverable and installable for users.
>  
>  For more information visit 
>  https://fedoraproject.org/wiki/Workstation/AddonAppdata 
I'd love to see more people attempting this. I started on a few of
these a while ago, but got disheartened when I got responses like
https://bugzilla.redhat.com/show_bug.cgi?id=1267628#c2 when I provided
patches.

Richard, is there any way we can carry metadata like this outside of
the actual SRPM when maintainers are unwilling to accept the metadata
in their package?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlZ4BygACgkQeiVVYja6o6Ns8ACfamaIe981Bw6FZzFtZhdqCLKV
PL0AoIIp0J+08ANSya8yNZ9sr48gORiu
=q6yR
-----END PGP SIGNATURE-----

[Richard Hughes]

On 21 December 2015 at 14:05, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  Richard, is there any way we can carry metadata like this outside of
>  the actual SRPM when maintainers are unwilling to accept the metadata
>  in their package? 
Unfortunately in the case of upstream being unhelpful, it does have to
be in the srpm, either in the .spec file itself (e.g. using <<EOF) or
as a referenced source and checked into git. I did try using an
external file to collect this a few releases ago, but the package
names (or subpackage names) very quickly went out of sync with the
extensions and it became really hard to maintain good quality
release-specific shared data. I really think the best place is
upstream, with downstream in Fedora used where required.

Richard

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 21, 2015 at 09:05:32AM -0500, Stephen Gallagher wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  On 12/21/2015 05:36 AM, Jiri Eischmann wrote:
>  > Hi, due to previous efforts we have a pretty good appdata coverage 
>  > of apps themselves, but add-ons (plugins, extensions,...) lag far 
>  > behind. There are dozens of useful GUI app add-ons in Fedora 
>  > repositories which don't have metadata files and are not exposed to
>  > users in GNOME Software. Let's focus on them.
>  > 
>  > The goal of this iniciative is to have a metadata file for every 
>  > useful add-on (for a GUI app) that is in Fedora repositories, so 
>  > that those add-ons appear in app profiles in Software and are 
>  > easily discoverable and installable for users.
>  > 
>  > For more information visit 
>  > https://fedoraproject.org/wiki/Workstation/AddonAppdata
>  
>  I'd love to see more people attempting this. I started on a few of
>  these a while ago, but got disheartened when I got responses like
>  https://bugzilla.redhat.com/show_bug.cgi?id=1267628#c2 when I provided
>  patches.
>  
>  Richard, is there any way we can carry metadata like this outside of
>  the actual SRPM when maintainers are unwilling to accept the metadata
>  in their package? 
I think that this is completely backwards. Either we, as the
distribution, decide that appstream is in, and pursue the
goal of implementing it, or we don't. We had a vote
[https://fedorahosted.org/fpc/ticket/414], appstream metadata
was approved as "SHOULD". I get it that maintainers don't want
to create appstream metadata on their own, but if somebody did
the work, I don't see a good excuse to refuse to put the file
in rpm. You add the file, add the two commands to test and install
the file, and that's about it. Our ability to implement new
technologies which reqire distribution-wide changes hinges on the
maintainers following the guidelines and at least passively allowing
others to implement the changes.

Zbyszek

[Richard Hughes]

On 21 December 2015 at 23:33, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  I think that this is completely backwards. Either we, as the
>  distribution, decide that appstream is in, and pursue the
>  goal of implementing it, or we don't. We had a vote
>  [https://fedorahosted.org/fpc/ticket/414], appstream metadata
>  was approved as "SHOULD". I get it that maintainers don't want
>  to create appstream metadata on their own, but if somebody did
>  the work, I don't see a good excuse to refuse to put the file
>  in rpm. 
IMHO, I think you are a pretty bad package (or upstream) maintainer if
you refuse to ship a *tiny* extra XML file that makes it easier for
users to install your stuff, even if you don't use an application
installer yourself.

Richard