New Application Status

[Tomasz Bojczuk]

Hi

Probably I'm one of the reasons this discussion started.
There is a new project https://invent.kde.org/graphics/karp which
passed the review and was moved from incubation to playground.
All by the book, I guess.
It is already at https://apps.kde.org i.e. but flatpack CI is not yet unlocked.
And here we are.

Project version is 25.03.70 so a stable release is planned for next spring.
But the project already benefited from being at the "official" gitlab repo.
Ben will know something about that - thank You by the way.
And thank You all in advance.
Seems like moving to https://invent.kde.org/graphics speed things up.

Kind regards
Tomasz

On Tue, Dec 3, 2024 at 9:21 AM Ben Cooksley <bcooksley at kde.org> wrote:
>
> On Tue, Dec 3, 2024 at 9:03 PM Ingo Klöcker <kloecker at kde.org> wrote:
>>
>> 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.
>
>
> Agreed - one is how we present our software to the world (apps.kde.org) while another reflects how we develop our software.
>
>>
>>
>> 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.
>
>
> We also have this same issue with handling archival / unmaintained status, which ideally should be pulled from the same lifecycle key.
> At the moment I think there are a couple of different mechanisms within the apps.kde.org generator codebase that determine this - which means that even after an application is marked as unmaintained and archived on GItlab it continues to show up on invent.kde.org.
>
>>
>> > 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.
>
>
> Would we have beta software that has passed KDE Review?
>
> The other thing we could do is suppress / not show the Discover/Appstream URL if it has not passed KDE Review.
>
>>
>>
>> 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'll also note that user namespaces are not writable to all developers, while our general purpose namespaces are (unless you explicitly add teams/kde-developers as a developer to your personal project that is).
>
> That being said though, we have not really been enforcing certain rules on non-reviewed projects (such as not being allowed to do stable releases, etc) so the benefits of being reviewed aside from qualifying for entry into Frameworks / Gear / Plasma aren't really material. Perhaps we should reinstate that.
>
>>
>> Regards,
>> Ingo
>
>
> Cheers,
> Ben