What means having an application in "KDE Applications"

[Luigi Toscano]

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