<div dir="ltr"><div>Hi all,</div><div><br></div><div>Trying to coming full circle on this here, but in summary sounds like there are a couple of things to change going forward:</div><div><br></div><div>* For <a href="http://apps.kde.org">apps.kde.org</a>, 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)</div><div>* We should institute tighter controls regarding releases of applications and ensuring projects pass KDE Review first</div><div><br></div><div>Thoughts?</div><div><br></div><div>Thanks,</div><div>Ben</div><div dir="ltr"><br></div><div dir="ltr">On Wed, Dec 4, 2024 at 12:59 PM Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@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">El dimarts, 3 de desembre del 2024, a les 10:26:35 (Hora estàndard del Centre <br>
d’Europa), Tomasz Bojczuk va escriure:<br>
> Hi<br>
> <br>
> Probably I'm one of the reasons this discussion started.<br>
> There is a new project <a href="https://invent.kde.org/graphics/karp" rel="noreferrer" target="_blank">https://invent.kde.org/graphics/karp</a> which<br>
> passed the review and was moved from incubation to playground.<br>
<br>
Naming maters here, karp did pass "incubation" not really [code/functionality] <br>
"review".<br>
<br>
That is, me as "incubation sponsor" only looked at the "logistical" aspects, <br>
if you look at <a href="https://invent.kde.org/graphics/karp/-/issues/1" rel="noreferrer" target="_blank">https://invent.kde.org/graphics/karp/-/issues/1</a> you will see <br>
all the checks are about licensing/manifesto/workflow/etc.<br>
<br>
I did not look at all if the code was good or if it would eat your files, <br>
that's what we have the "kdereview" step for.<br>
<br>
The "kdereview" step is mandatory (unless changed and I forgot) for making a <br>
release from <a href="http://kde.org" rel="noreferrer" target="_blank">kde.org</a> servers. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> All by the book, I guess.<br>
> It is already at <a href="https://apps.kde.org" rel="noreferrer" target="_blank">https://apps.kde.org</a> i.e. but flatpack CI is not yet<br>
> unlocked. And here we are.<br>
> <br>
> Project version is 25.03.70 so a stable release is planned for next spring.<br>
<br>
Are you aiming for inclusion in KDE Gear? (The number may seem you're aiming <br>
for that but also you may not).<br>
<br>
Cheers,<br>
  Albert<br>
<br>
> But the project already benefited from being at the "official" gitlab repo.<br>
> Ben will know something about that - thank You by the way.<br>
> And thank You all in advance.<br>
> Seems like moving to <a href="https://invent.kde.org/graphics" rel="noreferrer" target="_blank">https://invent.kde.org/graphics</a> speed things up.<br>
> <br>
> Kind regards<br>
> Tomasz<br>
> <br>
> On Tue, Dec 3, 2024 at 9:21 AM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br>
> > On Tue, Dec 3, 2024 at 9:03 PM Ingo Klöcker <<a href="mailto:kloecker@kde.org" target="_blank">kloecker@kde.org</a>> wrote:<br>
> >> On Dienstag, 3. Dezember 2024 01:17:41 Mitteleuropäische Normalzeit<br>
> >> Justin<br>
> >> <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<br>
> >> discuss them separately.<br>
> > <br>
> > Agreed - one is how we present our software to the world (<a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a>)<br>
> > while another reflects how we develop our software.> <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<br>
> >> the brand-new lifecycle attribute in repo-metadata to clearly mark apps<br>
> >> that haven't passed KDE Review as beta. I don't think that hiding them<br>
> >> from <a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a> is a fair solution. On the contrary, I think having<br>
> >> beta apps on <a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a> could possibly attract the attention of other<br>
> >> developers who'd be interested in working on a new app and of beta users<br>
> >> who'd be interested in giving the app a try. The possibility to get<br>
> >> early feedback is a key value of 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<br>
> >> documents<br>
> >> what differentiates playground projects from reviewed projects (although<br>
> >> this wiki page needs to be updated to mention the new lifecycle<br>
> >> attribute instead of the old projectpath attribute). I think it's just a<br>
> >> matter of making this information more visible to avoid wrong<br>
> >> expectations.<br>
> > <br>
> > We also have this same issue with handling archival / unmaintained status,<br>
> > which ideally should be pulled from the same lifecycle key. At the moment<br>
> > I think there are a couple of different mechanisms within the<br>
> > <a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a> generator codebase that determine this - which means that<br>
> > even after an application is marked as unmaintained and archived on<br>
> > GItlab it continues to show up on <a href="http://invent.kde.org" rel="noreferrer" target="_blank">invent.kde.org</a>.> <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<br>
> >> beta state could be communicated to Discover. Is there something<br>
> >> suitable in AppStream? I didn't see something obvious; we could probably<br>
> >> use tags. To avoid duplicate information this should somehow be added<br>
> >> automatically based on the lifecyle attribute in repo-metadata.<br>
> > <br>
> > Would we have beta software that has passed KDE Review?<br>
> > <br>
> > The other thing we could do is suppress / not show the Discover/Appstream<br>
> > URL if it has not passed KDE Review.> <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<br>
> >> KDE<br>
> >> Review is an excellent way to hide them from potential co-contributors.<br>
> >> Maybe it's just me because I don't read blogs, follow people on any s.m.<br>
> >> and don't scour GitLab user namespaces for interesting projects, but I<br>
> >> have never stumbled accidentally over an interesting project hidden in a<br>
> >> user namespace.> <br>
> > I'll also note that user namespaces are not writable to all developers,<br>
> > while our general purpose namespaces are (unless you explicitly add<br>
> > teams/kde-developers as a developer to your personal project that is).<br>
> > <br>
> > That being said though, we have not really been enforcing certain rules on<br>
> > non-reviewed projects (such as not being allowed to do stable releases,<br>
> > etc) so the benefits of being reviewed aside from qualifying for entry<br>
> > into Frameworks / Gear / Plasma aren't really material. Perhaps we should<br>
> > reinstate that.> <br>
> >> Regards,<br>
> >> Ingo<br>
> > <br>
> > Cheers,<br>
> > Ben<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>