New Application Status

[Ben Cooksley]

Hi all,

Trying to coming full circle on this here, but in summary sounds like there
are a couple of things to change going forward:

* For apps.kde.org, we should flag applications in accordance with their
Lifecycle status in the metadata (ie. unmaintained and those yet to pass
KDE Review should be flagged in some form or another)
* We should institute tighter controls regarding releases of applications
and ensuring projects pass KDE Review first

Thoughts?

Thanks,
Ben

On Wed, Dec 4, 2024 at 12:59 PM Albert Astals Cid <aacid at kde.org> wrote:

> El dimarts, 3 de desembre del 2024, a les 10:26:35 (Hora estàndard del
> Centre
> d’Europa), Tomasz Bojczuk va escriure:
> > 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.
>
> Naming maters here, karp did pass "incubation" not really
> [code/functionality]
> "review".
>
> That is, me as "incubation sponsor" only looked at the "logistical"
> aspects,
> if you look at https://invent.kde.org/graphics/karp/-/issues/1 you will
> see
> all the checks are about licensing/manifesto/workflow/etc.
>
> I did not look at all if the code was good or if it would eat your files,
> that's what we have the "kdereview" step for.
>
> The "kdereview" step is mandatory (unless changed and I forgot) for making
> a
> release from kde.org servers.


> > 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.
>
> Are you aiming for inclusion in KDE Gear? (The number may seem you're
> aiming
> for that but also you may not).
>
> Cheers,
>   Albert
>
> > 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20241205/d07646f2/attachment.htm>