New Application Status

Albert Astals Cid aacid at kde.org
Tue Dec 3 23:58:52 GMT 2024


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






More information about the kde-devel mailing list