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
