Applications Lifecycle Policy

[Martin Flöser]

Am 2017-07-05 22:18, schrieb Luigi Toscano:
> Martin Flöser ha scritto:
>> Am 2017-07-04 13:20, schrieb Jonathan Riddell:
>>> The applications lifecycle policy needs an update
>>> 
>>> Is this a good current state of it or are there more stages?
>>> 
>> 
>> Hi all,
>> 
>> I'm now going to propose a rather radical change to the process:
>> 
>> 1. Remove extragear
>> 2. Remove playground
>> 3. Remove the 2 week Review process
>> 
>> Let me explain the reasoning.
>> 
>> [...]
> Interesting, an annotation on this point:
> 
>> 
>> Today I think there are way better things to measure the quality than 
>> a two
>> week process on kde review:
>> 
>> * how many unit tests does a project have?
>> * how large is the test coverage?
>> * how often do tests fail on build.kde.org?
>> * how often does the build fail on build.kde.org?
>> * is it translated?
>> * does it have appstream data?
>> * is the code getting reviewed?
>> * is the project a one person show?
>> * ...
>> 
>> So instead of a one time review I would propose a continuous review of 
>> the
>> projects and make it available in an easy accessible way so that users 
>> can
>> also see the objective quality of the application. And yes that would 
>> mean
>> that many long standing applications would have a way lower quality 
>> than the
>> new kids on the block.
>> 
>> For KDE Applications, Plasma and Frameworks I expect to have 
>> additional rules
>> for integration. Frameworks already has them, Plasma kind of has them, 
>> but I
>> think they are not codified and KDE Applications could e.g. start with 
>> the
>> current review process.
>> 
>> So to sum it up: I don't think there is a need for extragear and 
>> playground
>> any more. When a project starts it should have the same rights and 
>> obligations
>> as any other current extragear app. In addition we should come up with
>> measurable quality facts and make them available to the community.
> 
> This is different from what Christian said (the "dumping ground is fine 
> even
> if some details are not relevant"). This process would make clear that 
> not all
> repositories are the same, and that's fine.
> 
> But please, if we end up going this way, make sure that we have the
> measurement report/dashboards in place for all projects *before* 
> changing the
> workflow.

Of course we should only change when we have a new workflow in place.

Cheers
Martin