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
