Applications Lifecycle Policy

[Christian Mollekopf]

On Wed, Jul 5, 2017, at 10:18 PM, Luigi Toscano wrote:
> 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.

It's to some extend different, it improves the situation by not only
having a quality badge of being
part of a release that requires to match certain review criterias, but
also improves it with
an individual quality assessment, which is a good thing (but will
require some work).

It also states that all projects still have the same obligations as
extragear, which is a change from what I proposed
and I don't see how that would really be applicable if you don't have a
playground to start.

Anyways, in general it is completely in my spirit; little upfront
requirements and then judge the quality
of what falls out of it.

Cheers,
Christian