New Application Status

[Nicolas Fella]

Am 03.12.24 um 09:02 schrieb Ingo Klöcker:
> On Dienstag, 3. Dezember 2024 01:17:41 Mitteleuropäische Normalzeit Justin
> Zobel wrote:
>> I'm a bit frustrated by our new application development pipeline.
>>
>> I see applications appear on apps.kde.org and in official namespaces on
>> GitLab before they have passed KDE Review.
> In my opinion you are conflating two completely different things. Let's discuss
> them separately.
>
> Let's start with apps.kde.org.
>
>> I feel this is falsely advertising to the world that the app is ready
>> for use.
> I agree that this could be improved. A possible solution would be to use the
> brand-new lifecycle attribute in repo-metadata to clearly mark apps that
> haven't passed KDE Review as beta. I don't think that hiding them from
> apps.kde.org is a fair solution. On the contrary, I think having beta apps on
> apps.kde.org could possibly attract the attention of other developers who'd be
> interested in working on a new app and of beta users who'd be interested in
> giving the app a try. The possibility to get early feedback is a key value of
> FOSS. "Release early. Release often."
>
> https://community.kde.org/Policies/Application_Lifecycle clearly documents
> what differentiates playground projects from reviewed projects (although this
> wiki page needs to be updated to mention the new lifecycle attribute instead
> of the old projectpath attribute). I think it's just a matter of making this
> information more visible to avoid wrong expectations.

I'd rephrase it around "Does it have a stable release?". If not then we
could show it under something like "Beta Applications".

That's a more user-relevant criterium than "Did it pass kdereview",
which is fairly internal and meaningless to most people.

Technically kdereview is a precondition for a stable release, so the end
result isn't much different. It would however prevent a situation where
the app is technically "reviewed" but there's still no installable release.

>> The button on apps.kde.org that says 'Install on Linux' takes me to
>> Discover and then tells me that the app was not found in any software
>> repositories.
> Is "passing KDE Review" really connected in any way to "packaged by some
> distro"? I guess that's a question only distro packagers can answer.
>
>> It also tells me to report this to my distribution which can lead to
>> noise on distro bug trackers. It can also lead to noise on the KDE bug
>> tracker because a user wants to install the application but can't.
> Discover probably shouldn't do this for beta apps. I have no idea how the beta
> state could be communicated to Discover. Is there something suitable in
> AppStream? I didn't see something obvious; we could probably use tags. To
> avoid duplicate information this should somehow be added automatically based
> on the lifecyle attribute in repo-metadata.

Discover uses the distributions Appstream pool. If the app is not
packaged in the distro Appstream doesn't know about this. As far as I
can tell there is no good way for Discover to distinguish between "This
app you told me to open doesn't exist" and "it exists but isn't packaged
in this distribution".

> Now GitLab namespaces
>
>> I think keeping applications in user namespaces until it has passed KDE
>> Review would solve both of these problems.
> I think keeping applications in user namespaces until they have passed KDE
> Review is an excellent way to hide them from potential co-contributors. Maybe
> it's just me because I don't read blogs, follow people on any s.m. and don't
> scour GitLab user namespaces for interesting projects, but I have never
> stumbled accidentally over an interesting project hidden in a user namespace.

I 100% agree. This proposal would introduce tons of obstacles for
collaboration, and I don't see any benefit for it whatsoever.

> Regards,
> Ingo

Cheers

Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20241203/189d3ed0/attachment.htm>