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. 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. 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 <bcooks...@kde.org> wrote: > > On Tue, Dec 3, 2024 at 9:03 PM Ingo Klöcker <kloec...@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
