New Application Status

[Ben Cooksley]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20241203/4577f5af/attachment.htm>