Re: flathub now supports tag, but which id to use for KDE? (was: Re: Defining a developer name for our applications metadata)

[Friedrich W. H. Kossebau]

Am Donnerstag, 22. Februar 2024, 15:58:53 CET schrieb Friedrich W. H. 
Kossebau:
> Am Dienstag, 30. Januar 2024, 18:34:46 CET schrieb Timothée Ravier:
> > Hi folks,
> > 
> > Flathub is now requiring that applications define a "developer_name" tag
> > in
> > their metadata (see [1], [2]).
> > 
> > What do folks think would be a good value for our application there?
> > 
> > Based on the suggestion in the documentation [3], I started making PRs [4]
> > [5] [6] [7] for our KDE Apps with "The KDE Community" as the
> > "developer_name" tag.
> 
> Seems meanwhile flathub maintainers have resolved that on their side, and
> now also support the non-deprecatd  tag, by what I learned in MR
> https://invent.kde.org/utilities/okteta/-/merge_requests/22
> 
> The proposed patch there raises another question here though and some tasks:
> --- 8< ---
>   
> KDE
>   
> --- 8< ---
> 
> Is "org.kde" (reverse-DNS) to be the official id, and is/could that be
> documented somewhere? accessibility-inspector currently uses even "https://
> kde.org", while others use "kde.org" (non-reverse DNS).
> 
> Given the purpose of the id is to be unique per group, this should be
> standardized, no? :)
> 
> Confusingly enough one doc talks about "tld.domain" as pattern of the id
> (flathub), while the other talks about "gnome.org" as example (appstream):
> 
> https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#name-summ
> ary-and-developer-name vs.
> https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-d
> eveloper

Update:

That confusion is now resolved as upstream was in the middle of updating docs.
And appstream docs now also recommend reverse-DNS notation:
--- 8< ---
The element should have a id property, containing a unique ID to identify the 
respective developer. It is recommended to use a reverse-DNS name, like 
org.gnome or io.github.ximion, or a Fediverse handle (like @u...@example.org) 
as ID to achieve a higher chance of uniqueness. 
--- 8< ---

> Tasks for people into this, please:
> 
> a) decide on an id here
> 
> b) document that id somewhere
> (e.g. https://develop.kde.org/docs/packaging/flatpak/ ?)

Left a respective note on
  https://invent.kde.org/teams/flathub/issues/-/issues/24#note_880623
and opened
  https://invent.kde.org/teams/flathub/issues/-/issues/25

> c) ask upstream to change the docs to not use "The KDE Community" as
> example, but "KDE" (and with no-translate attribute) in the respective
> docs:
> https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-> 
> developer

Not sure where to file. I hope the interested parties will see this and act on 
it, no time left myself to push things here.

Cheers
Friedrich

flathub now supports tag, but which id to use for KDE? (was: Re: Defining a developer name for our applications metadata)

[Friedrich W. H. Kossebau]

Am Dienstag, 30. Januar 2024, 18:34:46 CET schrieb Timothée Ravier:
> Hi folks,
> 
> Flathub is now requiring that applications define a "developer_name" tag in
> their metadata (see [1], [2]).
> 
> What do folks think would be a good value for our application there?
> 
> Based on the suggestion in the documentation [3], I started making PRs [4]
> [5] [6] [7] for our KDE Apps with "The KDE Community" as the
> "developer_name" tag.

Seems meanwhile flathub maintainers have resolved that on their side, and now 
also support the non-deprecatd  tag, by what I learned in MR 
https://invent.kde.org/utilities/okteta/-/merge_requests/22

The proposed patch there raises another question here though and some tasks:
--- 8< ---
  
KDE
  
--- 8< ---

Is "org.kde" (reverse-DNS) to be the official id, and is/could that be 
documented somewhere? accessibility-inspector currently uses even "https://
kde.org", while others use "kde.org" (non-reverse DNS).

Given the purpose of the id is to be unique per group, this should be 
standardized, no? :)

Confusingly enough one doc talks about "tld.domain" as pattern of the id 
(flathub), while the other talks about "gnome.org" as example (appstream):

https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#name-summary-and-developer-name
vs.
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer


Tasks for people into this, please:

a) decide on an id here

b) document that id somewhere
(e.g. https://develop.kde.org/docs/packaging/flatpak/ ?)

c) ask upstream to change the docs to not use "The KDE Community" as example, 
but "KDE" (and with no-translate attribute) in the respective docs:
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer

Cheers
Friedrich

Re: Defining a developer name for our applications metadata

[Johannes Zarl-Zierl]

Hi Albert,

Am Dienstag, 30. Jänner 2024, 22:27:22 CET schrieb Albert Astals Cid:
> "The KDE Community" is like "ATM Machine", KDE is *already* the community.

I have to say this is definitely *not* like "ATM Machine". At least I hope 
nobody is saying "the C in KDE stands for Community"... ;-)

Apart from that nitpick, no objection from me on either variant.

Cheers,
  Johannes

Re: Defining a developer name for our applications metadata

[Timothée Ravier]

On Fri, Feb 2, 2024 at 5:08 PM Johnny Jazeix  wrote:

> Hi,
>
> Just to be sure, do we know which appstream version do we use to validate
> our appdata files (
> https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/master/kde-modules/appstreamtest.cmake)
> and if the deprecated tag will issue a warning, an error or nothing in it?
>
> Cheers,
>
> Johnny
>

I've tested that `appstreamcli validate` gives no error/warning for this
tag on Fedora 39 & Rawhide (appstream 0.16.1 & 1.0.1) and Ubuntu 20.04
(0.12.10). The deprecation is only an info (not a warning) on appstream
1.0.1.

See also the Developer section from
https://planet.kde.org/matthias-klumpp-2023-11-11-appstream-1-0-released/.

-- 

Timothée Ravier

CoreOS co-Team Lead

Red Hat 

trav...@redhat.com

Re: Defining a developer name for our applications metadata

[Johnny Jazeix]

Hi,

Just to be sure, do we know which appstream version do we use to validate
our appdata files (
https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/master/kde-modules/appstreamtest.cmake)
and if the deprecated tag will issue a warning, an error or nothing in it?

Cheers,

Johnny


Le ven. 2 févr. 2024 à 16:56, Timothée Ravier  a écrit :

> Hi everyone,
>
> Following suggestions in the thread, I'll start updating our AppStream
> metadata with:
>
> ```
> KDE
> ```
>
> Thanks
> --
>
> Timothée Ravier
>
> CoreOS co-Team Lead
>
> Red Hat 
>
> trav...@redhat.com
> 
>

Re: Defining a developer name for our applications metadata

[Nate Graham]

Sounds good! Thanks for tackling this, Timothée.

Nate



On 2/2/24 08:55, Timothée Ravier wrote:

Hi everyone,

Following suggestions in the thread, I'll start updating our AppStream 
metadata with:


```
KDE
```

Thanks
--

Timothée Ravier

CoreOS co-Team Lead

Red Hat

trav...@redhat.com 

Re: Defining a developer name for our applications metadata

[Timothée Ravier]

Hi everyone,

Following suggestions in the thread, I'll start updating our AppStream
metadata with:

```
KDE
```

Thanks
-- 

Timothée Ravier

CoreOS co-Team Lead

Red Hat 

trav...@redhat.com

Re: Defining a developer name for our applications metadata

[Timothée Ravier]

On Wed, Jan 31, 2024 at 8:57 AM Ben Cooksley  wrote:

> Wait, so Flathub has begun requiring an older tag that the Appstream
> developers have deprecated?
>
> So we need to add tags to our metadata that are already deprecated and
> which are going to result in future failures of our own unit tests when
> upstream pulls the plug on developer_name as a tag and makes it a warning
> deprecation rather than an information deprecation?
>

See [1] & [2}. It's too soon to move to the new tags as they have just been
documented/introduced (for the new one) and deprecated (for the old one) in
the latest 1.0 Appstream release which requires changes for distributions
to adopt and thus won't be the norm for a while.

It's thus fine to use the old ones for now.

[1] https://github.com/flathub-infra/flatpak-builder-lint/issues/274
[2] https://github.com/flathub-infra/flatpak-builder-lint/issues/273

--

Timothée Ravier

CoreOS co-Team Lead

Red Hat 

trav...@redhat.com

Re: Defining a developer name for our applications metadata

[Matthias Klumpp]

Am Mi., 31. Jan. 2024 um 08:50 Uhr schrieb Ben Cooksley :

> On Wed, Jan 31, 2024 at 7:04 AM Timothée Ravier 
> wrote:
>
>> Hi folks,
>>
>> Flathub is now requiring that applications define a "developer_name" tag
>> in their metadata (see [1], [2]).
>>
>> What do folks think would be a good value for our application there?
>>
>> Based on the suggestion in the documentation [3], I started making PRs
>> [4] [5] [6] [7] for our KDE Apps with "The KDE Community" as the
>> "developer_name" tag.
>>
>
> Wait, so Flathub has begun requiring an older tag that the Appstream
> developers have deprecated?
>
> So we need to add tags to our metadata that are already deprecated and
> which are going to result in future failures of our own unit tests when
> upstream pulls the plug on developer_name as a tag and makes it a warning
> deprecation rather than an information deprecation?
>

Flathub is still transitioning away from old appstream-glib tooling to the
reference implementation, which will actually make it recognize all modern
features immediately and properly. Nobody thought that this would take
years and longer than AppStream 1.0 to be released, but it's happening.
I do not know the current status though, my last info was that Flathub had
switched, but that clearly doesn't seem to be fully the case yet...

The good thing is that the deprecation phase for this tag will be really,
really long - so it becoming a warning shouldn't be an issue for years.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Defining a developer name for our applications metadata

[Ben Cooksley]

On Wed, Jan 31, 2024 at 7:04 AM Timothée Ravier  wrote:

> Hi folks,
>
> Flathub is now requiring that applications define a "developer_name" tag
> in their metadata (see [1], [2]).
>
> What do folks think would be a good value for our application there?
>
> Based on the suggestion in the documentation [3], I started making PRs [4]
> [5] [6] [7] for our KDE Apps with "The KDE Community" as the
> "developer_name" tag.
>

Wait, so Flathub has begun requiring an older tag that the Appstream
developers have deprecated?

So we need to add tags to our metadata that are already deprecated and
which are going to result in future failures of our own unit tests when
upstream pulls the plug on developer_name as a tag and makes it a warning
deprecation rather than an information deprecation?


> I'm open to suggestions.
>
> Thanks,
>

Cheers,
Ben


>
> [1]
> https://docs.flathub.org/docs/for-app-authors/appdata-guidelines/#name-summary-and-developer-name
> [2]
> https://docs.flathub.org/docs/for-app-authors/linter/#appstream-missing-developer-name
> [3]
> https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer
> [4] https://invent.kde.org/graphics/gwenview/-/merge_requests/249
> [5] https://invent.kde.org/system/dolphin/-/merge_requests/708
> [6] https://invent.kde.org/multimedia/kdenlive/-/merge_requests/465
> [7] https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/531
>
> --
>
> Timothée Ravier
>
> CoreOS co-Team Lead
>
> Red Hat 
>
> trav...@redhat.com
> 
>

Re: Defining a developer name for our applications metadata

[Matthias Klumpp]

Am Di., 30. Jan. 2024 um 22:27 Uhr schrieb Albert Astals Cid :
>
> El dimarts, 30 de gener de 2024, a les 22:06:01 (CET), Nate Graham va
> escriure:
> > What sprang immediately to my mind was simply "KDE". Short and sweet.
>
> Agreed
>
> "The KDE Community" is like "ATM Machine", KDE is *already* the community.
>
> Also "KDE" works in all languages while "The KDE Community" is english-only.

The developer name is a translatable tag (but can be explicitly marked
as "do not translate" if that is not wanted, by setting
translate="no".

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Defining a developer name for our applications metadata

[Albert Astals Cid]

El dimarts, 30 de gener de 2024, a les 22:06:01 (CET), Nate Graham va 
escriure:
> What sprang immediately to my mind was simply "KDE". Short and sweet.

Agreed

"The KDE Community" is like "ATM Machine", KDE is *already* the community.

Also "KDE" works in all languages while "The KDE Community" is english-only.

Cheers,
  Albert

> 
> Nate
> 
> On 1/30/24 10:34, Timothée Ravier wrote:
> > Hi folks,
> > 
> > Flathub is now requiring that applications define a "developer_name" tag
> > in their metadata (see [1], [2]).
> > 
> > What do folks think would be a good value for our application there?
> > 
> > Based on the suggestion in the documentation [3], I started making PRs
> > [4] [5] [6] [7] for our KDE Apps with "The KDE Community" as the
> > "developer_name" tag.
> > 
> > I'm open to suggestions.
> > 
> > Thanks,
> > 
> > [1]
> > https://docs.flathub.org/docs/for-app-authors/appdata-guidelines/#name-sum
> > mary-and-developer-name
> >  > ummary-and-developer-name> [2]
> > https://docs.flathub.org/docs/for-app-authors/linter/#appstream-missing-de
> > veloper-name
> >  
> > > developer-name> [3]
> > https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-dev
> > eloper
> >  > eveloper> [4]
> > https://invent.kde.org/graphics/gwenview/-/merge_requests/249
> > 
> > [5] https://invent.kde.org/system/dolphin/-/merge_requests/708
> > 
> > [6] https://invent.kde.org/multimedia/kdenlive/-/merge_requests/465
> > 
> > [7] https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/531
> > 

Re: Defining a developer name for our applications metadata

[Nate Graham]

What sprang immediately to my mind was simply "KDE". Short and sweet.

Nate



On 1/30/24 10:34, Timothée Ravier wrote:

Hi folks,

Flathub is now requiring that applications define a "developer_name" tag 
in their metadata (see [1], [2]).


What do folks think would be a good value for our application there?

Based on the suggestion in the documentation [3], I started making PRs 
[4] [5] [6] [7] for our KDE Apps with "The KDE Community" as the 
"developer_name" tag.


I'm open to suggestions.

Thanks,

[1] 
https://docs.flathub.org/docs/for-app-authors/appdata-guidelines/#name-summary-and-developer-name 
[2] 
https://docs.flathub.org/docs/for-app-authors/linter/#appstream-missing-developer-name 
[3] 
https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer 
[4] https://invent.kde.org/graphics/gwenview/-/merge_requests/249 

[5] https://invent.kde.org/system/dolphin/-/merge_requests/708 

[6] https://invent.kde.org/multimedia/kdenlive/-/merge_requests/465 

[7] https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/531 



--

Timothée Ravier

CoreOS co-Team Lead

Red Hat

trav...@redhat.com 

Re: Defining a developer name for our applications metadata

[Johnny Jazeix]

Hi,

I recently added an application in flathub and found
https://discourse.flathub.org/t/deprecated-developer-name-element/5746
which is related to the subject.
I used appstreamcli to generate the appdata and it changes
 to .
The new format emits a warning on flathub linter (missing developer_name
tag).

Do you know if it has been fixed or if it can be an issue?

Cheers,

Johnny

Le mar. 30 janv. 2024 à 20:29, Ingo Klöcker  a écrit :

> On Dienstag, 30. Januar 2024 18:34:46 CET Timothée Ravier wrote:
> > Flathub is now requiring that applications define a "developer_name" tag
> in
> > their metadata (see [1], [2]).
> >
> > What do folks think would be a good value for our application there?
> >
> > Based on the suggestion in the documentation [3], I started making PRs
> [4]
> > [5] [6] [7] for our KDE Apps with "The KDE Community" as the
> > "developer_name" tag.
>
> I grepped my checked out repos and most use either "KDE Community" (9) or
> "The
> KDE Community" (5). lxr.kde.org find 25 times "KDE Community" (some with
> additional names) and 17 times "The KDE Community".
>
>
> https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=%5C%3Cdeveloper_name%5C%3EKDE+Community&_casesensitive=1
>
>
> https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=%5C%3Cdeveloper_name%5C%3EThe+KDE+Commu&_casesensitive=1
>
>
> Regards,
> Ingo
>

Re: Defining a developer name for our applications metadata

[Ingo Klöcker]

On Dienstag, 30. Januar 2024 18:34:46 CET Timothée Ravier wrote:
> Flathub is now requiring that applications define a "developer_name" tag in
> their metadata (see [1], [2]).
> 
> What do folks think would be a good value for our application there?
> 
> Based on the suggestion in the documentation [3], I started making PRs [4]
> [5] [6] [7] for our KDE Apps with "The KDE Community" as the
> "developer_name" tag.

I grepped my checked out repos and most use either "KDE Community" (9) or "The 
KDE Community" (5). lxr.kde.org find 25 times "KDE Community" (some with 
additional names) and 17 times "The KDE Community".

https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=%5C%3Cdeveloper_name%5C%3EKDE+Community&_casesensitive=1

https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=%5C%3Cdeveloper_name%5C%3EThe+KDE+Commu&_casesensitive=1


Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.

Defining a developer name for our applications metadata

[Timothée Ravier]

Hi folks,

Flathub is now requiring that applications define a "developer_name" tag in
their metadata (see [1], [2]).

What do folks think would be a good value for our application there?

Based on the suggestion in the documentation [3], I started making PRs [4]
[5] [6] [7] for our KDE Apps with "The KDE Community" as the
"developer_name" tag.

I'm open to suggestions.

Thanks,

[1]
https://docs.flathub.org/docs/for-app-authors/appdata-guidelines/#name-summary-and-developer-name
[2]
https://docs.flathub.org/docs/for-app-authors/linter/#appstream-missing-developer-name
[3]
https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer
[4] https://invent.kde.org/graphics/gwenview/-/merge_requests/249
[5] https://invent.kde.org/system/dolphin/-/merge_requests/708
[6] https://invent.kde.org/multimedia/kdenlive/-/merge_requests/465
[7] https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/531

-- 

Timothée Ravier

CoreOS co-Team Lead

Red Hat 

trav...@redhat.com