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
