Nate Graham ha scritto: > On 6/16/19 3:41 PM, Luigi Toscano wrote: >> Jonathan Riddell ha scritto: >>> On Fri, Jun 07, 2019 at 12:09:27AM +0200, Albert Astals Cid wrote: >>>> Can we please discuss what being in KDE Applications is first? >>>> >>>> You're telling apps they can join KDE Applications if they want, so to you >>>> it's just "release as a service". >>>> >>>> I disagree, to me it's a "we as a community vouch to try to maintain this >>>> to the best of our ability/time". >>>> >>>> So [to me] adding more things to KDE Applications needs at least a vague >>>> consensus that it's worth making that kind of promise. >>> >>> I think KDE should offer services to apps which want to be part of the >>> apps bundled release along with making the tars such as recommending >>> version number, promo, maybe helping out with packaging for Snaps and >>> Flatpaks and Appimage if there's teams happy to do that. >> >> I think that you are conflating the "help with the release" with the need for >> applications to be part of the bundle. >> >> My dream is an automated server-side tarball generation, in a way that >> developers can simply ask to release from a specific tag and don't care about >> uploading the file to the right place on the incoming ftp/ssh server. But >> that >> service could exist independently from the bundle. > > Can we please not turn every discussion about adding, removing, or modifying > apps in or to the bundle into into a discussion about the bundle's nature and > future? Every time we do this, it seems like nobody can agree on what we > should turn it into and nothing changes. If we're stuck with the status quo, > IMO let's just embrace it and use it. >
I may turn the question: can we please not propose every application for inclusion into KDE Applications on the basis of unproven reasons? See below. > I support adding things to the bundle that are currently being neglected in > terms of both development and release resources. Putting them into the bundle > seems like a good way to improve these things, rather than prerequisites to > doing it. The data shows that there is no correlation between a project being part of KDE Applications and how much it is taken care of. We have projects part of KDE Applications in a "stable" state, and that's fine. Sometimes sadly in a almost unmaintained state (the Telepathy stack). Sometimes they suffered during the Qt4->Qt5 transitions. Many times they are more than alive. The same can be said for projects outside KDE Applications. We have a lot of projects which are maintained. We have unmaintained ones. And we have an interesting of projects which have been resurrected, sometimes going from an unreleased Qt4 version to a fully released Qt 5 version. My point is that that if the main driver for the inclusion is raising the awareness about a certain project and attracting new developers, given that no data support this correlation, then maybe the inclusion itself should be questioned. -- Luigi