<div dir="ltr"><div dir="ltr">On Tue, Dec 3, 2024 at 9:03 PM Ingo Klöcker <<a href="mailto:kloecker@kde.org">kloecker@kde.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Dienstag, 3. Dezember 2024 01:17:41 Mitteleuropäische Normalzeit Justin <br>
Zobel wrote:<br>
> I'm a bit frustrated by our new application development pipeline.<br>
> <br>
> I see applications appear on <a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a> and in official namespaces on<br>
> GitLab before they have passed KDE Review.<br>
<br>
In my opinion you are conflating two completely different things. Let's discuss <br>
them separately.<br></blockquote><div><br></div><div>Agreed - one is how we present our software to the world (<a href="http://apps.kde.org">apps.kde.org</a>) while another reflects how we develop our software.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Let's start with <a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a>.<br>
<br>
> I feel this is falsely advertising to the world that the app is ready<br>
> for use.<br>
<br>
I agree that this could be improved. A possible solution would be to use the <br>
brand-new lifecycle attribute in repo-metadata to clearly mark apps that <br>
haven't passed KDE Review as beta. I don't think that hiding them from <br>
<a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a> is a fair solution. On the contrary, I think having beta apps on <br>
<a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a> could possibly attract the attention of other developers who'd be <br>
interested in working on a new app and of beta users who'd be interested in <br>
giving the app a try. The possibility to get early feedback is a key value of <br>
FOSS. "Release early. Release often."<br>
<br>
<a href="https://community.kde.org/Policies/Application_Lifecycle" rel="noreferrer" target="_blank">https://community.kde.org/Policies/Application_Lifecycle</a> clearly documents <br>
what differentiates playground projects from reviewed projects (although this <br>
wiki page needs to be updated to mention the new lifecycle attribute instead <br>
of the old projectpath attribute). I think it's just a matter of making this <br>
information more visible to avoid wrong expectations.<br></blockquote><div><br></div><div>We also have this same issue with handling archival / unmaintained status, which ideally should be pulled from the same lifecycle key.</div><div>At the moment I think there are a couple of different mechanisms within the <a href="http://apps.kde.org">apps.kde.org</a> 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 <a href="http://invent.kde.org">invent.kde.org</a>.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The button on <a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a> that says 'Install on Linux' takes me to<br>
> Discover and then tells me that the app was not found in any software<br>
> repositories.<br>
<br>
Is "passing KDE Review" really connected in any way to "packaged by some <br>
distro"? I guess that's a question only distro packagers can answer.<br>
<br>
> It also tells me to report this to my distribution which can lead to<br>
> noise on distro bug trackers. It can also lead to noise on the KDE bug<br>
> tracker because a user wants to install the application but can't.<br>
<br>
Discover probably shouldn't do this for beta apps. I have no idea how the beta <br>
state could be communicated to Discover. Is there something suitable in <br>
AppStream? I didn't see something obvious; we could probably use tags. To <br>
avoid duplicate information this should somehow be added automatically based <br>
on the lifecyle attribute in repo-metadata.<br></blockquote><div><br></div><div>Would we have beta software that has passed KDE Review?</div><div><br></div><div>The other thing we could do is suppress / not show the Discover/Appstream URL if it has not passed KDE Review.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Now GitLab namespaces<br>
<br>
> I think keeping applications in user namespaces until it has passed KDE<br>
> Review would solve both of these problems.<br>
<br>
I think keeping applications in user namespaces until they have passed KDE<br>
Review is an excellent way to hide them from potential co-contributors. Maybe <br>
it's just me because I don't read blogs, follow people on any s.m. and don't <br>
scour GitLab user namespaces for interesting projects, but I have never <br>
stumbled accidentally over an interesting project hidden in a user namespace.<br></blockquote><div><br></div><div>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).</div><div> </div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Ingo<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>