Adopting AppData in KDE?

[Thomas Lübking]

On Sonntag, 3. November 2013 16:28:56 CEST, Albert Astals Cid wrote:
> El Diumenge, 3 de novembre de 2013, a les 13:24:40, Richard Hughes va 
> escriure:
>> On 3 November 2013 12:32, Albert Astals Cid <aacid at kde.org> wrote:
>>> I am all for listing "high quality applications", it's just 
>>> that this just
>>> doesn't help.
>> 
>> Sure it does. We're not going to get AppData files for sodipodi,
>> cinepaint or arora any time soon. 
>
> But you said anyone can write one and submit it to Fedora for 
> submission, you 
> also said they're pretty trivial to write, so why do you think 
> I (or someone 
> else) can not write one for sodipodi and submit it?


I think everyone who read this thread was immediately aware that the "high quality applications" argument is "flawed" (i've actually another term in mind)

Qualification/certification requires a trustworthy instance, not some formalized README.
And the presence of an AppData description does neither indicate that the app is actually maintained (not now and certainly not in the long run, not even if you'd pervert the idea of a standard and alter it once a month), nor does the absence indicate that the app is of low quality (by measure of update frequency, some essential CLI tools would have to be considered "utter crap", because they work the way they are since a decade - and they do not even provide screenshots!!!)

The one and only point of forcing the apps to support AppData in order to be available is to enforce the AppData "standard".
If google videosearch would only find youtube videos, there'd be not the slightest doubt about that being a move in order to enforce (or at least "encourage") distribution via youtube and certainly not to assure "high quality videos" - of cats...


The important questions to ask and answer (well, "is it usable")
----------------------------------------------------------------
* does it presently qualify as "standard" at all? (not as long as it states particular tools - like gnome i18n, as claimed by David)
* what are the benefits of this particular standard over pot. competitors?
* what are the deficits of this particular standard?
* who is in control of the standard?
* what are the benefits in controlling the standard?
* What are the goals? Is it actually supposed to become a gatekeeper ("high quality applications" at best, "you use what i tell you"/"walled garden" at worst) tool?
* in case, by what technique (expert review, voting, etc.), ie. who becomes the gatekeeper?

No serious answer to the above could include buzz like "high quality" or "awesome".

Cheers,
Thomas