Re: [kde-community] Re: Applications Lifecycle Policy

[Albert Astals Cid]

El dimecres, 26 de juliol de 2017, a les 12:39:12 CEST, Jonathan Riddell va 
escriure:
> At the BoF today we approved the draft lifecycle policy as a
> reflection of current practice.
> 
> One addition is that apps in kdereview should take no more than two
> months and after that should be moved to unmaintained or back to
> playground.
> 
> More notes were taken on discussion about improving the review process
> which Luigi will send.

Notes at https://notes.kde.org/p/akademy-2017-application-lifecycle

It seems to me in the BoF there was a general consensus (even though it may be 
just me projecting) that having kdereview for now is better than having 
nothing. Once we get those great new tests, it seems everyone was happy with 
removing/simplifying greatly the kdereview step.

Now what we need is a group to step up, collect the checks we do on the 
kdereview step (some of them are in the notes) and write those checks.

Best Regards,
  Albert

> 
> Jonathan
> 
> On 24 July 2017 at 18:51, Volker Krause  wrote:
> > We'll have a BoF for that on Wednesday 11:30 in room 2.4.
> > 
> > On Sunday, 23 July 2017 19:08:12 CEST Valorie Zimmerman wrote:
> >> Hello folks, I would just like to ask if there is a BoF scheduled
> >> about this? Has a Phab board been created? As a GSoC admin for KDE, we
> >> are always trying to urge/require students to include writing tests as
> >> part of their daily coding, as well as documenting their code /
> >> creating APIdox / writing user docs.
> >> 
> >> If the group of developers interested in creating this thinks that
> >> this testing regimen is too difficult to get done in a short time, how
> >> about creating a plan for a prospective Season of KDE student? Some
> >> sort of infobox on every application website that continuously reports
> >> test coverage, translation/internationalization/localization
> >> statistics and other relevant information could be very useful. A
> >> number of you interested people could be resources for such a student
> >> or students.
> >> 
> >> We are already making the idea of seeking review for commits desirable
> >> and even standard in KDE. The same could be true for automated test
> >> coverage of the entire KDE codebase.
> >> 
> >> Valorie
> >> 
> >> On Mon, Jul 17, 2017 at 10:21 AM, Sandro Knauß  wrote:
> >> > Hey,
> >> > 
> >> >> Having automated checks would be great but I see no practical proposal
> >> >> for
> >> >> how to get those.  I'm not even sure it's possible to automate
> >> >> questions
> >> >> like "should this be translated?" or "are all the licences clear?".
> >> > 
> >> > well for "are all the licences clear?" are several tools to check the
> >> > license for files. That at least would give us the first step, if we
> >> > would arrange, that every file must be detectable by this tool. I could
> >> > also create a script, that simply can be fired to the repos.
> >> > 
> >> > Than at last manual step to check if the different license work
> >> > together
> >> > is a lot faster, because you know already the different licenses of all
> >> > the files.
> >> > 
> >> > Best Regards,
> >> > 
> >> > sandro
> > 
> > --
> > Volker Krause | volker.kra...@kdab.com | Director Automotive
> > KDAB (Deutschland) GmbH KG, a KDAB Group company
> > Tel. +49-30-521325470
> > KDAB - The Qt, C++ and OpenGL Experts

Re: [kde-community] Re: Applications Lifecycle Policy

[Volker Krause]

We'll have a BoF for that on Wednesday 11:30 in room 2.4.

On Sunday, 23 July 2017 19:08:12 CEST Valorie Zimmerman wrote:
> Hello folks, I would just like to ask if there is a BoF scheduled
> about this? Has a Phab board been created? As a GSoC admin for KDE, we
> are always trying to urge/require students to include writing tests as
> part of their daily coding, as well as documenting their code /
> creating APIdox / writing user docs.
> 
> If the group of developers interested in creating this thinks that
> this testing regimen is too difficult to get done in a short time, how
> about creating a plan for a prospective Season of KDE student? Some
> sort of infobox on every application website that continuously reports
> test coverage, translation/internationalization/localization
> statistics and other relevant information could be very useful. A
> number of you interested people could be resources for such a student
> or students.
> 
> We are already making the idea of seeking review for commits desirable
> and even standard in KDE. The same could be true for automated test
> coverage of the entire KDE codebase.
> 
> Valorie
> 
> On Mon, Jul 17, 2017 at 10:21 AM, Sandro Knauß  wrote:
> > Hey,
> > 
> >> Having automated checks would be great but I see no practical proposal
> >> for
> >> how to get those.  I'm not even sure it's possible to automate questions
> >> like "should this be translated?" or "are all the licences clear?".
> > 
> > well for "are all the licences clear?" are several tools to check the
> > license for files. That at least would give us the first step, if we
> > would arrange, that every file must be detectable by this tool. I could
> > also create a script, that simply can be fired to the repos.
> > 
> > Than at last manual step to check if the different license work together
> > is a lot faster, because you know already the different licenses of all
> > the files.
> > 
> > Best Regards,
> > 
> > sandro


-- 
Volker Krause | volker.kra...@kdab.com | Director Automotive
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel. +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

signature.asc
Description: This is a digitally signed message part.

Re: [kde-community] Re: Applications Lifecycle Policy

[Sandro Knauß]

Hey,

> Having automated checks would be great but I see no practical proposal for
> how to get those.  I'm not even sure it's possible to automate questions
> like "should this be translated?" or "are all the licences clear?".

well for "are all the licences clear?" are several tools to check the license 
for files. That at least would give us the first step, if we would arrange, 
that 
every file must be detectable by this tool. I could also create a script, that 
simply can be fired to the repos.

Than at last manual step to check if the different license work together is a 
lot faster, because you know already the different licenses of all the files.

Best Regards,

sandro

Re: [kde-community] Re: Applications Lifecycle Policy

[Martin Gräßlin]

Am 17. Juli 2017 18:19:43 MESZ schrieb Jonathan Riddell :
>On Mon, Jul 17, 2017 at 06:01:39PM +0200, Martin Flöser wrote:
>> Am 2017-07-17 17:47, schrieb Jonathan Riddell:
>> >I propose to make this final if there's no further comments.
>> 
>> as I explained: I think the review process should be removed,
>> playground should be removed.
>> 
>> There were both people supporting the idea and people being against.
>> Given that I don't think there is a consensus yet.
>
>Having automated checks would be great but I see no practical proposal
>for how to get those.  I'm not even sure it's possible to automate
>questions like "should this be translated?" or "are all the licences
>clear?".

And no human will find it. Especially not for large applications and our 
already existing applications.

But there are things which can easily be automated:
• check whether there is a copying file
• check whether all source files have a valid copyright header
• check whether Messages.sh exists
• run what scripty does

The practical proposal is: get a room during Akademy and discuss what can be 
automated. Put that down on phabricator and let's work together to get it done. 
If I get a way to verify that KWin has everything properly translated 
automatically and not two years later in bug reports.

We are hackers - I don't accept answers like who is going to implement this. We 
just do! And yes that implies that I will try to help.

Cheers
Martin

Re: [kde-community] Re: Applications Lifecycle Policy

[Jonathan Riddell]

On Mon, Jul 17, 2017 at 06:01:39PM +0200, Martin Flöser wrote:
> Am 2017-07-17 17:47, schrieb Jonathan Riddell:
> >I propose to make this final if there's no further comments.
> 
> as I explained: I think the review process should be removed,
> playground should be removed.
> 
> There were both people supporting the idea and people being against.
> Given that I don't think there is a consensus yet.

Having automated checks would be great but I see no practical proposal for how 
to get those.  I'm not even sure it's possible to automate questions like 
"should this be translated?" or "are all the licences clear?".

Jonathan

Re: Applications Lifecycle Policy

[Luigi Toscano]

On Monday, 17 July 2017 18:01:39 CEST Martin Flöser wrote:
> Am 2017-07-17 17:47, schrieb Jonathan Riddell:
> > I propose to make this final if there's no further comments.
> 
> as I explained: I think the review process should be removed, playground
> should be removed.
> 
> There were both people supporting the idea and people being against.
> Given that I don't think there is a consensus yet.

That's true, but if the proposed image is a better representation of the 
status quo than the currrent image, it could at least be used in place of the 
old one, and the discussion can proceed.

-- 
Luigi

Re: Applications Lifecycle Policy

[Martin Flöser]

Am 2017-07-12 00:20, schrieb Albert Astals Cid:

El dimecres, 5 de juliol de 2017, a les 21:37:09 CEST, Martin Flöser va
escriure:

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:


3. Remove the 2 week Review process


If we don't have review, at which point do i say:
 * Your i18n handling is broken
 * Your library installed headers will be a pain to maintain ABI
 * etc

Never?

The review process for me is a way to make you realize that things you 
didn't

think were important now suddenly are since you want to be a grownup.


Please see my other replies to this thread which also discuss how I 
imagine this to work for the translation team.




Of course you can break it again later but I would like to hope that 
once told
how to do those things properly it may be easier to keep them doing 
right


Right, like KWin where I am the fourth maintainer after review. That's 
my whole point: replace the review with automated checks always running.


Cheers
Martin

Re: Applications Lifecycle Policy

[Albert Astals Cid]

El dimecres, 5 de juliol de 2017, a les 21:37:09 CEST, Martin Flöser va 
escriure:
> 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:
> 
>
> 3. Remove the 2 week Review process

If we don't have review, at which point do i say:
 * Your i18n handling is broken
 * Your library installed headers will be a pain to maintain ABI
 * etc

Never?

The review process for me is a way to make you realize that things you didn't 
think were important now suddenly are since you want to be a grownup.

Of course you can break it again later but I would like to hope that once told 
how to do those things properly it may be easier to keep them doing right

Cheers,
  Albert

Re: Applications Lifecycle Policy

[Luca Beltrame]

Il giorno Thu, 06 Jul 2017 07:44:49 +0200
Martin Gräßlin  ha scritto:

> could we get a transcript of the discussion on IRC?

It was on the Italian KDE dev channel, so even if I had a
transcript, it would be hardly useful. ;) It was just a couple of
points, saying that we need more automated checks, and that
unfortunately this isn't sexy so it's still a lacking area.


pgpHgyKiwdhdl.pgp
Description: Firma digitale OpenPGP

Re: Applications Lifecycle Policy

[Kevin Ottens]

Hello,

I don't want to dive too much in this particular thread. A couple of things 
I'd like to bring though. I won't quote what I agree with but just what 
worries me a bit.

On Wednesday, 5 July 2017 21:37:09 CEST Martin Flöser wrote:
> [...]
> With extragear gone I don't really see the need of playground any more.
> Playground applications are just like all the other things, except that
> they did not go through KDE Review. Which brings me to the next point:
> remove the review.
> 
> To me the review process always felt weird and also like a relict from
> other times. I contributed to overall KDE something like 100 k lines of
> new code - none of them went through review. Would KWin pass review
> today? Just for the fun I opened up Krazy and see 444 open issues.
> Objectively speaking KWin is known as one of the products with highest
> quality in the KDE area and one of the window managers with highest
> quality and the Wayland compositor with largest test coverage. On the
> other hand it would fail our rules for review (granted Krazy reports so
> many false positives in the case of KWin, that I didn't check for
> years).
> 
> KWayland entered frameworks without review. How come? Well it moved from
> Plasma to frameworks, so no review needed. How did it enter Plasma? Well
> it was split out of KWin. Back then it was a few files providing a very
> minimal library for Wayland clients. If we had started in Playground we
> would have had to go through review - today it's a code base of 50 k
> (according to cloc). Similar if we would have started a new Wayland
> compositor from scratch it would have had to go through review, but by
> extending KWin that was never needed.
> 
> I see that the review process is there to ensure a "baselevel quality".
> But what is afterwards? When did KWin go through review? When Matthias
> forked it from KWM, or was it covered by KWM? That makes something like
> 15 years of nobody looking at this baselevel quality. Would we have
> needed it sometimes? Hell yes! Think of the compositor introduction, the
> xcb port, the Wayland port. To large parts like new products, but we
> passed review once (if at all) so it was no longer needed.
> 
> Similar we see now for Kube. If it would have started as a "KMail 3" no
> review would be needed, but as Kube it needs to go through review.
> That's arbitrary.

I don't think that is arbitrary. There are lots of differences happening 
because it didn't get started in the kmail or kdepim repository. Same thing 
for Zanshin which had discrepancies in dealing with the translations or how 
the releases were done. They wouldn't have happened if it was started as part 
of kdepim or korganizer because you tend to mimic more when you grow within 
something already established. We found those issues during the kdereview 
phase and I'm glad it happened.

> If I would start a new project I would think that this process is a joke.
> The quality just doesn't get measured any more after review.

Now I agree that claiming kdereview is about quality is kind of a delusional 
especially since it happens only once as you mentioned. To me it's really to 
make sure it gets properly inserted in the rest of our infrastructure (for 
translations, making releases, etc.) which might require changes either to the 
application or the infrastructure. kdereview is the right time to find those.

> 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?
> * ...

Out of curiosity, what happens to projects which are a one person show? We got 
loads of those. Sink and Zanshin being in that set IMO.

Sink and Zanshin get a few commits here and there from other people but really 
90%+ of the work is done by Christian and me respectively.

> 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.

I don't think that excludes having a defined point in time for the first one. 
I even think that's necessary because we're not quite good at doing this kind 
of continuous reviews. I like the idea otherwise.

> 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.

On Frameworks the point in time for the initial review is known though, it's 
when the flip is 

Re: Applications Lifecycle Policy

[Martin Gräßlin]

Am 6. Juli 2017 07:10:01 MESZ schrieb Luca Beltrame :
>Il giorno Thu, 06 Jul 2017 07:07:06 +0200
>Martin Flöser  ha scritto:
>
>> I understand your point: you don't want that the quality assurance
>> ends up on the shoulders of the distros. And I agree.
>
>See my other response (with changed subject) in the thread. The
>discussion we had on IRC pointed out that perhaps, instead of less
>checks, we would want more automated checks, like you mention further
>down in this reply.

could we get a transcript of the discussion on IRC?

Re: Applications Lifecycle Policy

[Martin Flöser]

Am 2017-07-05 23:29, schrieb David Edmundson:

2. Remove playground


Lots of projects get started and die.

I think it's important to have some flag (however you want to call it)
that says; CI admins, translators and even packagers should not bother
looking at this project yet.  Otherwise we waste a lot of people's
time.

The review process in it's current reality is mostly an extension of
that, with the people checking those things off.

There is little actual code review, it's mostly CMake and i18n.


You bring up good points! One is: we don't detect when applications die. 
We need to improve there.


My answer to the other points is similar to what I already answered to 
Luca: we need to establish clear rules.


Our translation team needs to come up with requirements they need 
fulfilled so that translations get enabled, you don't just get it.
On the other hand I would say that to release you need translation 
setups.


And of course I want that CI covered! E.g. we could run scripty in CI 
stage and verify that messages get extracted.


My point basically is the same as the base one: we do the review once. 
I'm not saying the steps of the review are not needed, they are super 
important. But we don't ensure it afterwards and that's why I think the 
current review process is broken.


Cheers
Martin

Re: Applications Lifecycle Policy

[Luca Beltrame]

Il giorno Thu, 06 Jul 2017 07:07:06 +0200
Martin Flöser  ha scritto:

> I understand your point: you don't want that the quality assurance
> ends up on the shoulders of the distros. And I agree.

See my other response (with changed subject) in the thread. The
discussion we had on IRC pointed out that perhaps, instead of less
checks, we would want more automated checks, like you mention further
down in this reply.

(I cut this reply down to move the discussion to the other one, since
this is only tangential to lifecycle policy).

-- 
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B


pgpvde6ZdVzDx.pgp
Description: Firma digitale OpenPGP

Re: Applications Lifecycle Policy

[Martin Flöser]

Am 2017-07-05 22:27, schrieb Luca Beltrame:

Il giorno Wed, 05 Jul 2017 21:37:09 +0200
Martin Flöser  ha scritto:


To me the review process always felt weird and also like a relict
from other times. I contributed to overall KDE something like 100 k


While projects with strong stewardship like KWin, Plasma or Krita
(*not* implying there aren't others: I'm mentioning the ones
that come to mind) ensure a continued review and code quality, how
would you ensure that, without review periods (or anything that can
subsitute them, if anything better) distributions and integrators don't
get code dumps of dubious quality?

I see this as a concrete risk.


I understand your point: you don't want that the quality assurance ends 
up on the shoulders of the distros. And I agree.


My proposal addresses this by wanting our CI to do the work for us. And 
I would say we introduce rules on when an application is allowed to 
release. This could be requirements like:


* translation setup is working
* code compiles on CI
* code installs correctly
* ...

In fact I think currently we do a bad job on ensuring that the code can 
be used by distributions. That's something we don't have in our review 
process but which is needed. And those are things we can check 
automatically, like does it have a COPYING file.


To you this change would mean: if there is a tarball the requirements 
for release from our side are fulfilled, which you currently don't have.


So also here I see a potential for we can become better by changing the 
workflow.


Cheers
Martin

Re: Applications Lifecycle Policy

[Luca Beltrame]

Il giorno Wed, 5 Jul 2017 22:54:50 +0200 (CEST)
Boudewijn Rempt  ha
scritto:

> I suck at code review, personally... I can only see what's wrong with
> code once I get a bug report and have to fix the code.

If someone tries to ship you code that does not compile, you'll notice
that, though. ;) I meant at least for the process to catch the most
obvious errors:

1. Compile errors (see the kio-stash review thread)
2. Failing tests (again see that thread)
3. Obvious licensing issues (makes the life of a downstream easier) 
4. Improper i18n/l10n setup

-- 
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B


pgpLVIQ_LjE0s.pgp
Description: Firma digitale OpenPGP

Re: 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

Re: Applications Lifecycle Policy

[David Edmundson]

> 2. Remove playground
>

Lots of projects get started and die.

I think it's important to have some flag (however you want to call it) that
says; CI admins, translators and even packagers should not bother looking
at this project yet.  Otherwise we waste a lot of people's time.

The review process in it's current reality is mostly an extension of that,
with the people checking those things off.
There is little actual code review, it's mostly CMake and i18n.

Re: Applications Lifecycle Policy

[Boudewijn Rempt]

On Wed, 5 Jul 2017, Luca Beltrame wrote:

> While projects with strong stewardship like KWin, Plasma or Krita
> (*not* implying there aren't others: I'm mentioning the ones
> that come to mind) ensure a continued review and code quality, how
> would you ensure that, without review periods (or anything that can
> subsitute them, if anything better) distributions and integrators don't
> get code dumps of dubious quality?

I suck at code review, personally... I can only see what's wrong with code
once I get a bug report and have to fix the code.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Release code review and quality (was Re: Applications Lifecycle Policy)

[Luca Beltrame]

Il giorno Wed, 05 Jul 2017 22:33:13 +0200
Christian Mollekopf 
ha scritto:

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

Honest question: onto whom would the burden fall? As a contributor
towards integration I wouldn't want that to fall (solely) on my
shoulders. 

I mean, we're all humans and things slip through the cracks all the
time, even with review. Removing even a light (emphasis on *light*)
scrutiny would make things worse.

I would argue, as proposed by Luigi on IRC just now, that we should
have perhaps less *human* checks but more *automated* checks. This is
however orthogonal to the discussion on lifecycle.


-- 
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B


pgpg7flGlpzRx.pgp
Description: Firma digitale OpenPGP

Re: 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

Re: Applications Lifecycle Policy

[Luca Beltrame]

Il giorno Wed, 05 Jul 2017 21:37:09 +0200
Martin Flöser  ha scritto:

> To me the review process always felt weird and also like a relict
> from other times. I contributed to overall KDE something like 100 k

While projects with strong stewardship like KWin, Plasma or Krita
(*not* implying there aren't others: I'm mentioning the ones
that come to mind) ensure a continued review and code quality, how
would you ensure that, without review periods (or anything that can
subsitute them, if anything better) distributions and integrators don't
get code dumps of dubious quality?

I see this as a concrete risk.

-- 
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B


pgp9LA4nDFjJa.pgp
Description: Firma digitale OpenPGP

Re: Applications Lifecycle Policy

[Christian Mollekopf]

On Wed, Jul 5, 2017, at 09:37 PM, Martin Flöser wrote:
> 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

I just wanted to say that this very much aligns with my thinking and
just explains it much better than I did.

Thanks!

Re: Applications Lifecycle Policy

[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.

Ciao
-- 
Luigi

Re: Applications Lifecycle Policy

[Luigi Toscano]

Boudewijn Rempt ha scritto:
> On Wed, 5 Jul 2017, Martin Flöser wrote:
>> Extragear: to me extragear is a relict from the time of the big one KDE svn
>> trunk repository. There was "KDE" and everything else, aka. extragear. When I
>> started to compile KDE software it looked to me like something created from
>> the needs of SVN. A technical thing. Now we have git and we have split up all
>> those parts which used to be KDE, except for extragear. Where is the
>> difference between Krita (to my knowledge not part of extragear), 
> 
> It isn't -- for some reasons I don't exactly understand, it's still part of
> calligra in some kind of hierarchy, though not in the repo.

Clarification about this point: it was in a hierarchy because porting
(internal) the tool out of the hierarchy needs manpower which is not around,
so Krita needed a place, and it was easier to keep it under the "calligra"
namespace. That said, in the internal place where it is required, it can be
moved to extragear-graphics. Again, only important until some work is done.

Ciao
-- 
Luigi

Re: Applications Lifecycle Policy

[Boudewijn Rempt]

On Wed, 5 Jul 2017, Martin Flöser wrote:

> 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.
> 
> Extragear: to me extragear is a relict from the time of the big one KDE svn
> trunk repository. There was "KDE" and everything else, aka. extragear. When I
> started to compile KDE software it looked to me like something created from
> the needs of SVN. A technical thing. Now we have git and we have split up all
> those parts which used to be KDE, except for extragear. Where is the
> difference between Krita (to my knowledge not part of extragear), 

It isn't -- for some reasons I don't exactly understand, it's still part of
calligra in some kind of hierarchy, though not in the repo.

> Amarok (to
> my knowledge part of extragear) and Dolphin (to my knowledge part of KDE
> Applications)? Honestly I don't see it.
> 
> Let's just remove it and separate into applications released as part of a
> larger bundle for release simplification and applications having their own
> release cycle.

Yeah.

> 
> To me the review process always felt weird and also like a relict from other
> times. I contributed to overall KDE something like 100 k lines of new code -
> none of them went through review. Would KWin pass review today? Just for the
> fun I opened up Krazy and see 444 open issues. Objectively speaking KWin is
> known as one of the products with highest quality in the KDE area and one of
> the window managers with highest quality and the Wayland compositor with
> largest test coverage. On the other hand it would fail our rules for review
> (granted Krazy reports so many false positives in the case of KWin, that I
> didn't check for years).

Same here. Nearly 10k commits later, I'm not sure Krita would get through 
review,
let alone that that there would be someone capable of reviewing it...

> KWayland entered frameworks without review. How come? Well it moved from
> Plasma to frameworks, so no review needed. How did it enter Plasma? Well it
> was split out of KWin. Back then it was a few files providing a very minimal
> library for Wayland clients. If we had started in Playground we would have had
> to go through review - today it's a code base of 50 k (according to cloc).
> Similar if we would have started a new Wayland compositor from scratch it
> would have had to go through review, but by extending KWin that was never
> needed.

Good point.

<...>
 
> Similar we see now for Kube. If it would have started as a "KMail 3" no review
> would be needed, but as Kube it needs to go through review. That's arbitrary.
> If I would start a new project I would think that this process is a joke. The
> quality just doesn't get measured any more after review.

Excellent point.

<...>

> * is the project a one person show?

Poor Gimp... Poor mitchfoo.

> 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

While I don't have any stake in this discussion -- when I die, there'll be this 
on my headstone "Here lies Boud, he worked on Krita, boring guy, otherwise" --
I really agree with the way you're thinking.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Applications Lifecycle Policy

[Martin Flöser]

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.

Extragear: to me extragear is a relict from the time of the big one KDE 
svn trunk repository. There was "KDE" and everything else, aka. 
extragear. When I started to compile KDE software it looked to me like 
something created from the needs of SVN. A technical thing. Now we have 
git and we have split up all those parts which used to be KDE, except 
for extragear. Where is the difference between Krita (to my knowledge 
not part of extragear), Amarok (to my knowledge part of extragear) and 
Dolphin (to my knowledge part of KDE Applications)? Honestly I don't see 
it.


Let's just remove it and separate into applications released as part of 
a larger bundle for release simplification and applications having their 
own release cycle.


With extragear gone I don't really see the need of playground any more. 
Playground applications are just like all the other things, except that 
they did not go through KDE Review. Which brings me to the next point: 
remove the review.


To me the review process always felt weird and also like a relict from 
other times. I contributed to overall KDE something like 100 k lines of 
new code - none of them went through review. Would KWin pass review 
today? Just for the fun I opened up Krazy and see 444 open issues. 
Objectively speaking KWin is known as one of the products with highest 
quality in the KDE area and one of the window managers with highest 
quality and the Wayland compositor with largest test coverage. On the 
other hand it would fail our rules for review (granted Krazy reports so 
many false positives in the case of KWin, that I didn't check for 
years).


KWayland entered frameworks without review. How come? Well it moved from 
Plasma to frameworks, so no review needed. How did it enter Plasma? Well 
it was split out of KWin. Back then it was a few files providing a very 
minimal library for Wayland clients. If we had started in Playground we 
would have had to go through review - today it's a code base of 50 k 
(according to cloc). Similar if we would have started a new Wayland 
compositor from scratch it would have had to go through review, but by 
extending KWin that was never needed.


I see that the review process is there to ensure a "baselevel quality". 
But what is afterwards? When did KWin go through review? When Matthias 
forked it from KWM, or was it covered by KWM? That makes something like 
15 years of nobody looking at this baselevel quality. Would we have 
needed it sometimes? Hell yes! Think of the compositor introduction, the 
xcb port, the Wayland port. To large parts like new products, but we 
passed review once (if at all) so it was no longer needed.


Similar we see now for Kube. If it would have started as a "KMail 3" no 
review would be needed, but as Kube it needs to go through review. 
That's arbitrary. If I would start a new project I would think that this 
process is a joke. The quality just doesn't get measured any more after 
review.


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.


Cheers
Martin

Re: Applications Lifecycle Policy

[Jonathan Riddell]

On 5 July 2017 at 13:54, Jaroslaw Staniek  wrote:

> Thanks, I'd think not "earlier stage" but explicitly "playground" because in
> the meantime the unmaintained project might lost its "reviewed" stamp.
> Technology and other requirements move forward. Example: unmaintained
> project XYZ got restored from Qt4 times to Qt6, needs major changes for
> translation and build systems.


OK updated

Jonathan

Re: [kde-community] Re: Applications Lifecycle Policy

[Jonathan Riddell]

> Maybe something like:
>
> "Documentation appropriate to the project: API documentation, user
> documentation (including docbook or other format documented by the
> Documentation team)"

Updated

Jonathan

Re: Applications Lifecycle Policy

[Jonathan Riddell]

On 5 July 2017 at 13:04, Jaroslaw Staniek  wrote:
> Why not? I can imagine we can make the process more dynamic.
> Whole apps or their parts can go back to being maintained, what seems to be
> a core property of FOSS.
>
> If so how about back-arrow from Unmaintained?

Probably not worth making the diagram more complex but I added in this
sentence to unmaintained section

"Projects can move back to an earlier stage if they are picked up for
maintenance again. "

Jonathan

Re: Applications Lifecycle Policy

[Jonathan Riddell]

I added in a requirement for released apps so they can't release with
unreleased software deps

* These projects should depend only on stable released software (or
software known it will get a stable release before the project does).

Jonathan

Re: Applications Lifecycle Policy

[Jaroslaw Staniek]

On 4 July 2017 at 13:20, Jonathan Riddell <j...@jriddell.org> wrote:

> The applications lifecycle policy needs an update
>
> Is this a good current state of it or are there more stages?
>
> https://community.kde.org/Policies/Application_Lifecycle/Draft
>
> Jonathan
>

Hi
Looking good. One thing: is there life after "unmaintained"?

Why not? I can imagine we can make the process more dynamic.
Whole apps or their parts can go back to being maintained, what seems to be
a core property of FOSS.

If so how about back-arrow from ​Unmaintained?

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek

Re: [kde-community] Re: Applications Lifecycle Policy

[Jonathan Riddell]

On Wed, Jul 05, 2017 at 01:45:14PM +0200, Luigi Toscano wrote:
> Jonathan Riddell ha scritto:
> 
> > I used the Sanity Checklist I made for the releasing extragear page as
> > the list of some stuff people will look at in kdereview
> >  https://techbase.kde.org/ReleasingExtragearSoftware#Sanity_Checklist
> > what else should go in here?  It doesn't require docbook docs, they
> > seem to be out of fashion.
> 
> Can we make this point still valid? If you don't like docbook, fine, but docs
> should be still a requirement (maybe not for KIOs, but apps should have docs).

How's this line I added to sanity checklist?

"Documentation appropriate to the project. This could be docbook in the Git 
repo, a userbase page or API documentation."

https://techbase.kde.org/ReleasingExtragearSoftware#Sanity_Checklist

Jonathan

Re: Applications Lifecycle Policy

[Luigi Toscano]

Harald Sitter ha scritto:
> On Wed, Jul 5, 2017 at 7:01 AM, Christian Mollekopf

>>From where I am standing we should have a stage before playground.
> Scratch repos if you will (although those are slated for deprecation
> without replacement). This addresses the code-dumping github-like use
> case, no tickets, little overhead. If it doesn't work out you throw it
> away. This gives us an actual playground: "I need no translations, no
> CI, no nothing, I am prototyping here" (think pre-alpha). From there
> it can proceed to playground (alpha stage). This is automatically a
> submission for continuous(?) casual review. It is at this point under
> joint ownership so we ought to assert our policies hence the casual
> review. Once ready (as determined by the authors) it moves to
> frameworks/plasma/applications.
> I understand this is a bit of a hippie workflow, but think about it
> this way: the reason we don't just review playground is that it's
> potentially little to no code and/or heavily rotating code, neither of
> which makes it easy to do a review. If the software is out of initial
> protoyping we have code to review and it's far less rotating already
> (the degree of rotation matters little, as the assumption continues to
> be that once we assert our policies they will get continuously
> implemented by the author). At the same time this removes almost all
> the policy overhead of moving from playground to the final
> destination. The code is already reviewed, all it takes is a ticket to
> become a proper application.
> 
> TLDR: instead of making people not get too comfortable in playground
> make them more likely to want to move to applications (by making that
> super easy)

My first question after reading is: what is the difference between
playground -> kdereview -> other
and
scratch -> playground -> other
?

Still a 2 phase process. Maybe the only change is that playground would be
less time limited than the current kdereview.
I would say that moving from scratch -> playground would be probably
announced, like the current move to kdereview; I only fear that a more
implicit (even if announced) call to review would be less effective than the
current one (with all its limitations).

-- 
Luigi
> 
> HS
> 

Re: Applications Lifecycle Policy

[Luigi Toscano]

Christian Mollekopf ha scritto:

> Overall I just find the cost/benefit factor in the beginning of a
> project not at all good when using KDE infrastructure.
> I have to request repos and can't just create them, I have to request
> tarballs to be uploaded instead of just uploading them, I have to apply
> for CI instead of just doing it, etc. Personally, if I was not already
> rooted in KDE I wouldn't bother and just use github. (I know that it may
> be that not all of those friction points are by design, but more by lack
> of manpower.)

You address few interesting point but I think that they are ortogonal to this
discussion. Or better, that they can be discussed and solved independently
without touching the application lifecycle.
This is for repository creation (which I think it may be also blocked until we
switch fully to phabricator, apart from the non-technical policy), more
automation in the upload, and the requirement about the CIs (which I
personally think should be enabled for every project).


> 
> Now that equation starts to change later in the project if you i.e. join
> regular releases, have translations etc. but initially it's IMO just
> bad. That's of course exactly the baseline/dumpingground argument;
> either you try to attract projects and thus lower the minimum bar as far
> as possible, or you have some requirements. I don't think a bunch of
> crappy repositories hurt a lot and could be kept in check IMO, so I
> would go for the former, allowing projects to easily evolve and i.e. at
> some stage decide to become part of an Applications release after
> passing review.
> If my project started on github though, and I consequently already setup
> distribution channels etc externally, then that barrier is way higher.

Being in a community has a cost, which is balanced by being in the community.

> 
> But yeah, I'd be fine with any random project coming on KDE
> infrastructure if it sees KDE as the place to be. Some might be shitty,
> some might be great, some might have translations, some might not, some
> might die after a couple of months, some might prosper for years. I
> think it would be great to have more diversity and I don't really think
> we have to protect the quality of anything and everything that is on KDE
> infrastructure, that's what i.e. Applications and Frameworks releases
> are good for.

We are doing is already, and there will always be a cost (even with
automation, I wouldn't open some process to people without a developer account).

-- 
Luigi

Re: Applications Lifecycle Policy

[Luigi Toscano]

Jonathan Riddell ha scritto:

> I used the Sanity Checklist I made for the releasing extragear page as
> the list of some stuff people will look at in kdereview
>  https://techbase.kde.org/ReleasingExtragearSoftware#Sanity_Checklist
> what else should go in here?  It doesn't require docbook docs, they
> seem to be out of fashion.

Can we make this point still valid? If you don't like docbook, fine, but docs
should be still a requirement (maybe not for KIOs, but apps should have docs).


-- 
Luigi

Re: Applications Lifecycle Policy

[Jonathan Riddell]

I've added in the various other release methods, apps,kf5 and plasma
and filled in text as I see it.

https://community.kde.org/Policies/Application_Lifecycle/Draft

Are the module coordinators still used and a sensible way to get into
KDE Applications?
 https://community.kde.org/Release_Team#Coordinator_List

I used the Sanity Checklist I made for the releasing extragear page as
the list of some stuff people will look at in kdereview
 https://techbase.kde.org/ReleasingExtragearSoftware#Sanity_Checklist
what else should go in here?  It doesn't require docbook docs, they
seem to be out of fashion.  It EBN and krazy still valid?

I said stuff should go into unmaintained if it's no longer useful,
with a suggestion to ask the KDE Gardening team to look after it.  Is
the gardening team still active?

Jonathan



On 4 July 2017 at 12:20, Jonathan Riddell <j...@jriddell.org> wrote:
> The applications lifecycle policy needs an update
>
> Is this a good current state of it or are there more stages?
>
> https://community.kde.org/Policies/Application_Lifecycle/Draft
>
> Jonathan

Re: [kde-community] Re: Applications Lifecycle Policy

[Jonathan Riddell]

On Wed, Jul 05, 2017 at 11:44:40AM +0200, Harald Sitter wrote:
> We do not review the maintenance of the baseline we established during
> review. I am guessing we do not re-review because the expectation is
> that the authors are able to follow our community policies after the
> initial review. Fair assumption for sure. BUT if we, KDE, are to be
> trusted to maintain the baseline without re-review, then why are we
> not trusted to write new software with that same baseline?

It's useful to have an initial review, stuff gets brought up in kdereview all 
the time.

Problems which occur after kdereview will typically be brought up during the 
release process, often packagers will pick them up.

It's not ideal but it's a bit like the copyright files in Debian packaging, it 
gets reviewed by ftpmaster on first upload and just trusted thereafter. 
Sometimes they bitrot a bit and sometimes they don't but at least a minimum is 
set at the start to get it on its way.

Jonathan

Re: Applications Lifecycle Policy

[Milian Wolff]

On Wednesday, July 5, 2017 12:06:50 AM CEST Ingo Klöcker wrote:
> On Tuesday 04 July 2017 23:34:20 Christian Mollekopf wrote:
> > What I meant to propose was more that instead of being initially in a
> > temporary location,
> > and then having to choose one of "proper" ones and go through review,
> > we would instead
> > start with a permanent location and then you "could" become part of a
> > release with requirements
> > and therefore review. In general I just think the barrier to release a
> > project from KDE infrastructure
> > should be lowered not raised.
> 
> To me this sounds as if you want the KDE infrastructure to become a
> dumping ground for low-quality, untranslated stuff, i.e. just like
> github except with the KDE badge. Yes, I'm exaggerating, but essentially
> that's how I understand what you are saying.
> 
> I agree with Albert, Ben, and Luigi, that we (at least the four of us)
> don't want this.

+1

-- 
Milian Wolff
m...@milianw.de
http://milianw.de

Re: Applications Lifecycle Policy

[Harald Sitter]

On Wed, Jul 5, 2017 at 7:01 AM, Christian Mollekopf
 wrote:
>> This comes again from the diversity in view: for me the review, with all
>> its limits, it's the baseline.
>> As showed in the discussion, releasing from playground is not more
>> complicated than other type of releases.
>
> Yes, I'm fine with that. I just wanted to make sure releasing from
> playground doesn't require any exceptions but is regular procedure.
>
>> It's just when it becomes "too much" that
>> people start asking "why not go for a proper review". It's not different in 
>> my
>> opinion from new contributor submitting patches until someone see that
>> it's "too much" and start asking "why don't you get a proper account".
>
> Essentially managing the system by applying some peer pressure to get
> people out of playground.
> Personally I don't find that necessary but it's a valid approach of
> course.

Releasing from playground ad infinitum seems to have some disagreement.

As was already pointed out, once the cost/benefit ratio becomes
acceptable most devs will probably just go for review anyway.
Playground becomes a disadvantage when you need a stable branch with
l10n for example. Ultimately the cost is more on the review side I
think, more than anything else anyway. If it wasn't for the review
it'd be a matter of filing some paperwork to get the move done.

There are two problems which seem to get ignored with reviews though
and they ultimately play into the projects-arent-moving-to-kdereview .

1. Our manifesto establishes shared ownership of software licensed
under an acceptable free software license and using our established
practices. Yet we do not verify or enforce this up until the project
gets to kdereview. At which point it may well have had 50 distinct
contributors claiming copyright under the GPLv1 making relicensing a
right hassle.
2.  While kdereview certainly establishes a baseline quality, unless
the software dies right after review or gets 0 feature development
(both of which aren't good I'd say) the longer it exists the shittier
it gets as the time since review keeps growing.

I guess the question is really: What is playground?

Is it us, KDE, writing new software?
or is it
Someone else writing new software?

And as a consequence of that: Why do we have this hurdle to get out of
playground?

We do not review the maintenance of the baseline we established during
review. I am guessing we do not re-review because the expectation is
that the authors are able to follow our community policies after the
initial review. Fair assumption for sure. BUT if we, KDE, are to be
trusted to maintain the baseline without re-review, then why are we
not trusted to write new software with that same baseline?

For new stuff that comes in via incubation the review is certainly
sound. If nothing else it asserts our policies on the pre-existing
code base. If the authors continue to implement the community policies
after review, is assumed but not verified, they are now KDE, so they
are trusted to maintain this level.

Food for thought.

(to make this clear: I am not necessarily saying kdereview as a step
needs to go, I am saying we are turning a blind eye to the fact that
we take no measure to maintain review quality rendering the notion of
reviews sem-moot, all the while our new and most vulnerable code sits
there potentially incorrectly licensed)

>From where I am standing we should have a stage before playground.
Scratch repos if you will (although those are slated for deprecation
without replacement). This addresses the code-dumping github-like use
case, no tickets, little overhead. If it doesn't work out you throw it
away. This gives us an actual playground: "I need no translations, no
CI, no nothing, I am prototyping here" (think pre-alpha). From there
it can proceed to playground (alpha stage). This is automatically a
submission for continuous(?) casual review. It is at this point under
joint ownership so we ought to assert our policies hence the casual
review. Once ready (as determined by the authors) it moves to
frameworks/plasma/applications.
I understand this is a bit of a hippie workflow, but think about it
this way: the reason we don't just review playground is that it's
potentially little to no code and/or heavily rotating code, neither of
which makes it easy to do a review. If the software is out of initial
protoyping we have code to review and it's far less rotating already
(the degree of rotation matters little, as the assumption continues to
be that once we assert our policies they will get continuously
implemented by the author). At the same time this removes almost all
the policy overhead of moving from playground to the final
destination. The code is already reviewed, all it takes is a ticket to
become a proper application.

TLDR: instead of making people not get too comfortable in playground
make them more likely to want to move to applications (by making that
super easy)

HS

Re: Applications Lifecycle Policy

[Luca Beltrame]

Il giorno Tue, 04 Jul 2017 23:04:08 +0200
Christian Mollekopf 
ha scritto:

> * it should be ok to release from playground for years, or even
> potentially forever.

That would impact translations, and IMO it can be easily abused as a
"get out of jail free" card that avoids kdereview. 
While I understand the motivations behind it, I don't think it's
feasible. I can however understand going from playground for a
"while".

> should be possible to release from extragear forever. Perhaps some
> project is just not interested in translations for instance...)

From extragear it's already the case. It simply means "project has its
own schedule not tied to Plasma, Applications, or Frameworks". 

> * Abolishing the extragear/applications differentiation at this level
> would make more sense to me (extragear does have a second class feel

That would cause a bit of issue wrt releases, since:

a. extragear go on their own releases (see Krita for a big example of
this)
b. Applications releases have predictable, time-based releases which
not all projects would like to subject to

Re: Applications Lifecycle Policy

[Luigi Toscano]

Christian Mollekopf ha scritto:
> 
> 
> On Tue, Jul 4, 2017, at 11:16 PM, Luigi Toscano wrote:
>> Christian Mollekopf ha scritto:
>>> On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote:
>>>> The applications lifecycle policy needs an update
>>>>
>>>> Is this a good current state of it or are there more stages?
>>>>
>>>> https://community.kde.org/Policies/Application_Lifecycle/Draft
>>>>
>>>
>>> Looks good to me for what it currently is.
>>>
>>> In general I think:
>>> * it should be ok to release from playground for years, or even
>>> potentially forever.
>>
>> Even stable releases? I disagree.
>>
> 
> Yes. I realize that this would be a change from the current situation,
> but I don't think it would hurt.
> It would essentially allow applications to either get the extra quality
> badge or not as they see fit.

Just to stress again: I don't think it's about extra quality, but baseline
quality.

> 
>>> * going to extragear/applications should be an extra quality badge where
>>> you sign up for certain requirements (which is why I think it should be
>>> possible to release from extragear forever. Perhaps some project is just
>>> not interested in translations for instance...)
>>
>> I totally disagree. If an application is not interested in the
>> translations (or other "details" which should be level 0) and the 
>> maintainership does
>> not even agree to outsource the work for the maintainance of the
>> translations, I would question whether the application is fit for the KDE 
>> community at
>> all.
> 
> Ok, but I wouldn't. I think it could be perfectly viable for some
> application to say that i.e.
> because we only target the scientific community (I'm making some random
> example up),
> we just assume they speak english and don't care about the rest.
> 
> My point is not specifically about translations, it's about requirements
> in general and whether it
> makes sense to find a "one size fits all" barrier that all applications
> have to pass.
> 

I understood your point, but a review is about many things (starting from the
general test from someone else external to the project, to - say -
expectations in the code, to cmake structure if applicable,  to translations
(which are always fit so far). My point is don't assume that something is not
fit because there could not be "one size fits all"; some things may not fit
but let's find out after, not a priori.
(and we already lowered the requirements, see documentation).

>>
>>> * Abolishing the extragear/applications differentiation at this level
>>> would make more sense to me (extragear does have a second class feel to
>>> it), instead applications should just declare that they are part of the
>>> applications release. This would indeed also ease transitioning between
>>> releases and dealing with the versioning should be up to the maintainers
>>> (of course versions that go down are not at all something that should be
>>> accepted ever anywhere).
>>
>>
>> So basically change
>>
>> kdereview
>> -> KDE Applications
>> -> KDE Extragear
>> -> KDE Frameworks
>> -> KDE Plasma
>> (as mentioned by Jonathan, we are missing the last two in the graph)
>>
>> with something like
>>
>> kdereview -> reviewed (Frameworks, KDE Plasma, "KDE Applications",
>> independent release schedule).
>>
>> That sound fine, with one caveat: without having the 4 entities in
>> separate nodes of the graph we can't describe the transition between 
>> modules. You
>> wrote that this would "ease transitioning", but I think that we may want to
>> capture for example the transition from "any" to Frameworks, which has 
>> specific
>> rules.
>> And so on.
> 
> What I meant to propose was more that instead of being initially in a
> temporary location,
> and then having to choose one of "proper" ones and go through review, we
> would instead
> start with a permanent location and then you "could" become part of a
> release with requirements
> and therefore review. In general I just think the barrier to release a
> project from KDE infrastructure
> should be lowered not raised.


This comes again from the diversity in view: for me the review, with all its
limits, it's the baseline.
As showed in the discussion, releasing from playground is not more complicated
than other type of releases. It's just when it becomes "too much" that people
start asking "why not go for a proper review". It's not different in my
opinion from new contributor submitting patches until someone see that it's
"too much" and start asking "why don't you get a proper account".

Unless... do you (generic) have specific cases when people could fear the
review? That's the part that I don't understand.
For example, would you (specific) have some reason to not have a review for
the 4 modules that were just reviewed for pim, up to Kube?

Ciao
-- 
Luigi

Re: Applications Lifecycle Policy

[Ingo Klöcker]

On Tuesday 04 July 2017 23:34:20 Christian Mollekopf wrote:
> What I meant to propose was more that instead of being initially in a
> temporary location,
> and then having to choose one of "proper" ones and go through review,
> we would instead
> start with a permanent location and then you "could" become part of a
> release with requirements
> and therefore review. In general I just think the barrier to release a
> project from KDE infrastructure
> should be lowered not raised.

To me this sounds as if you want the KDE infrastructure to become a 
dumping ground for low-quality, untranslated stuff, i.e. just like 
github except with the KDE badge. Yes, I'm exaggerating, but essentially 
that's how I understand what you are saying.

I agree with Albert, Ben, and Luigi, that we (at least the four of us) 
don't want this.


Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.

Re: Applications Lifecycle Policy

[Christian Mollekopf]

On Tue, Jul 4, 2017, at 11:16 PM, Luigi Toscano wrote:
> Christian Mollekopf ha scritto:
> > On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote:
> >> The applications lifecycle policy needs an update
> >>
> >> Is this a good current state of it or are there more stages?
> >>
> >> https://community.kde.org/Policies/Application_Lifecycle/Draft
> >>
> > 
> > Looks good to me for what it currently is.
> > 
> > In general I think:
> > * it should be ok to release from playground for years, or even
> > potentially forever.
> 
> Even stable releases? I disagree.
> 

Yes. I realize that this would be a change from the current situation,
but I don't think it would hurt.
It would essentially allow applications to either get the extra quality
badge or not as they see fit.

> > * going to extragear/applications should be an extra quality badge where
> > you sign up for certain requirements (which is why I think it should be
> > possible to release from extragear forever. Perhaps some project is just
> > not interested in translations for instance...)
> 
> I totally disagree. If an application is not interested in the
> translations (or other "details" which should be level 0) and the 
> maintainership does
> not even agree to outsource the work for the maintainance of the
> translations, I would question whether the application is fit for the KDE 
> community at
> all.

Ok, but I wouldn't. I think it could be perfectly viable for some
application to say that i.e.
because we only target the scientific community (I'm making some random
example up),
we just assume they speak english and don't care about the rest.

My point is not specifically about translations, it's about requirements
in general and whether it
makes sense to find a "one size fits all" barrier that all applications
have to pass.

> 
> > * Abolishing the extragear/applications differentiation at this level
> > would make more sense to me (extragear does have a second class feel to
> > it), instead applications should just declare that they are part of the
> > applications release. This would indeed also ease transitioning between
> > releases and dealing with the versioning should be up to the maintainers
> > (of course versions that go down are not at all something that should be
> > accepted ever anywhere).
> 
> 
> So basically change
> 
> kdereview
> -> KDE Applications
> -> KDE Extragear
> -> KDE Frameworks
> -> KDE Plasma
> (as mentioned by Jonathan, we are missing the last two in the graph)
> 
> with something like
> 
> kdereview -> reviewed (Frameworks, KDE Plasma, "KDE Applications",
> independent release schedule).
> 
> That sound fine, with one caveat: without having the 4 entities in
> separate nodes of the graph we can't describe the transition between modules. 
> You
> wrote that this would "ease transitioning", but I think that we may want to
> capture for example the transition from "any" to Frameworks, which has 
> specific
> rules.
> And so on.

What I meant to propose was more that instead of being initially in a
temporary location,
and then having to choose one of "proper" ones and go through review, we
would instead
start with a permanent location and then you "could" become part of a
release with requirements
and therefore review. In general I just think the barrier to release a
project from KDE infrastructure
should be lowered not raised.

Cheers,
Christian

PS: If I don't reply anymore that is because I'm about to board a plane.

Re: Applications Lifecycle Policy

[Ben Cooksley]

On Wed, Jul 5, 2017 at 9:04 AM, Christian Mollekopf
<chrig...@fastmail.fm> wrote:
> On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote:
>> The applications lifecycle policy needs an update
>>
>> Is this a good current state of it or are there more stages?
>>
>> https://community.kde.org/Policies/Application_Lifecycle/Draft
>>
>
> Looks good to me for what it currently is.
>
> In general I think:
> * it should be ok to release from playground for years, or even
> potentially forever.

Sorry, but I disagree there. Releasing from Playground is allowed
merely to allow developers to get feedback from early adopters (who
understand the software may possess kittens, open blackholes and start
a zombie uprising)
Once an application is ready (or is being used) for production
purposes by users (and it's own developers count as users) then it
should be headed to Extragear/Applications.

We're doing ourselves a disservice by not reviewing each others code
for issues, which is something KDE Review helps facilitate.

> * going to extragear/applications should be an extra quality badge where
> you sign up for certain requirements (which is why I think it should be
> possible to release from extragear forever. Perhaps some project is just
> not interested in translations for instance...)

Pretty sure that not allowing translations is a violation of various
commitments which are expected of KDE software as it impedes
accessibility and usability by portions of our user base.

> * Abolishing the extragear/applications differentiation at this level
> would make more sense to me (extragear does have a second class feel to
> it), instead applications should just declare that they are part of the
> applications release. This would indeed also ease transitioning between
> releases and dealing with the versioning should be up to the maintainers
> (of course versions that go down are not at all something that should be
> accepted ever anywhere).
>
> Cheers,
> Christian

Regards,
Ben

Re: Applications Lifecycle Policy

[Luigi Toscano]

Christian Mollekopf ha scritto:
> On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote:
>> The applications lifecycle policy needs an update
>>
>> Is this a good current state of it or are there more stages?
>>
>> https://community.kde.org/Policies/Application_Lifecycle/Draft
>>
> 
> Looks good to me for what it currently is.
> 
> In general I think:
> * it should be ok to release from playground for years, or even
> potentially forever.

Even stable releases? I disagree.

> * going to extragear/applications should be an extra quality badge where
> you sign up for certain requirements (which is why I think it should be
> possible to release from extragear forever. Perhaps some project is just
> not interested in translations for instance...)

I totally disagree. If an application is not interested in the translations
(or other "details" which should be level 0) and the maintainership does not
even agree to outsource the work for the maintainance of the translations, I
would question whether the application is fit for the KDE community at all.


> * Abolishing the extragear/applications differentiation at this level
> would make more sense to me (extragear does have a second class feel to
> it), instead applications should just declare that they are part of the
> applications release. This would indeed also ease transitioning between
> releases and dealing with the versioning should be up to the maintainers
> (of course versions that go down are not at all something that should be
> accepted ever anywhere).


So basically change

kdereview
-> KDE Applications
-> KDE Extragear
-> KDE Frameworks
-> KDE Plasma
(as mentioned by Jonathan, we are missing the last two in the graph)

with something like

kdereview -> reviewed (Frameworks, KDE Plasma, "KDE Applications", independent
release schedule).

That sound fine, with one caveat: without having the 4 entities in separate
nodes of the graph we can't describe the transition between modules. You wrote
that this would "ease transitioning", but I think that we may want to capture
for example the transition from "any" to Frameworks, which has specific rules.
And so on.

-- 
Luigi

Re: Applications Lifecycle Policy

[Christian Mollekopf]

On Tue, Jul 4, 2017, at 01:20 PM, Jonathan Riddell wrote:
> The applications lifecycle policy needs an update
> 
> Is this a good current state of it or are there more stages?
> 
> https://community.kde.org/Policies/Application_Lifecycle/Draft
> 

Looks good to me for what it currently is.

In general I think:
* it should be ok to release from playground for years, or even
potentially forever.
* going to extragear/applications should be an extra quality badge where
you sign up for certain requirements (which is why I think it should be
possible to release from extragear forever. Perhaps some project is just
not interested in translations for instance...)
* Abolishing the extragear/applications differentiation at this level
would make more sense to me (extragear does have a second class feel to
it), instead applications should just declare that they are part of the
applications release. This would indeed also ease transitioning between
releases and dealing with the versioning should be up to the maintainers
(of course versions that go down are not at all something that should be
accepted ever anywhere).

Cheers,
Christian

Re: Applications Lifecycle Policy

[Jonathan Riddell]

On Tue, Jul 04, 2017 at 01:43:32PM +0200, Kevin Ottens wrote:
> Hello,
> 
> On Tuesday, 4 July 2017 13:20:43 CEST Jonathan Riddell wrote:
> > The applications lifecycle policy needs an update
> > 
> > Is this a good current state of it or are there more stages?
> > 
> > https://community.kde.org/Policies/Application_Lifecycle/Draft
> 
> Didn't we have cases of applications moving between KDE Applications and 
> Extragear?

Occationally, at last extragear to apps I seem to remember.  It's
potentially problematic when it happens because of the change in
version numbers, distros don't like them to go down.

I have missed Plasma and Frameworks from the diagram which seems like an 
oversight.

Jonathan

Re: [kde-community] Re: Applications Lifecycle Policy

[Luigi Toscano]

On Tuesday, 4 July 2017 14:27:07 CEST Jonathan Riddell wrote:
> On Tue, Jul 04, 2017 at 02:24:30PM +0200, Luigi Toscano wrote:
> > Are we focusing on the graph for now, and then we can move to the content
> > of the page, or can we start the general discussion as well?
> 
> Go wild :)
> 

I think that we need to expand the step about moving to unmaintained. It's 
really rare that someone writes "I'm abandoning this", so we may want to find 
some other conditions.
For example, change of underlying Qt and program not ported? We have many 
applications like this in "extragear" (still kdelibs4).

-- 
Luigi

Re: [kde-community] Re: Applications Lifecycle Policy

[Jonathan Riddell]

On Tue, Jul 04, 2017 at 02:24:30PM +0200, Luigi Toscano wrote:
> Are we focusing on the graph for now, and then we can move to the content of 
> the page, or can we start the general discussion as well?

Go wild :)

Jonathan

Re: Applications Lifecycle Policy

[Luigi Toscano]

On Tuesday, 4 July 2017 13:20:43 CEST Jonathan Riddell wrote:
> The applications lifecycle policy needs an update
> 
> Is this a good current state of it or are there more stages?
> 
> https://community.kde.org/Policies/Application_Lifecycle/Draft

Are we focusing on the graph for now, and then we can move to the content of 
the page, or can we start the general discussion as well?

The proposed graph is fine by me, and it solves the issue with applications 
coming from the Incubation which ended into playground while they should have 
gone directly to kdereview.
I think that a separate "playground" has still value in defining some kind of 
line where the application has been released. "Extragear" here already means 
"whatever is released with its own release cycle not in the big bundles", as 
we basically officially removed that word from public usage.

-- 
Luigi

Re: Applications Lifecycle Policy

[Harald Sitter]

On Tue, Jul 4, 2017 at 1:43 PM, Kevin Ottens <er...@kde.org> wrote:
> Hello,
>
> On Tuesday, 4 July 2017 13:20:43 CEST Jonathan Riddell wrote:
>> The applications lifecycle policy needs an update
>>
>> Is this a good current state of it or are there more stages?
>>
>> https://community.kde.org/Policies/Application_Lifecycle/Draft
>
> Didn't we have cases of applications moving between KDE Applications and
> Extragear?

Probably.

I do wonder if we can, maybe, get rid of Extragear as a thing
altogether. Extragear applications are KDE applications on their own
release schedule. At least for the purposes of the lifecycle I'd think
they are one and the same. Separating them by name only and calling
one "extra" kind of implies that the others are
common/normal/standard/default, when in fact they are simply released
at different points in time but otherwise the same.

Tearing down this artificial wall may well incline extragear apps that
have a particularly irregular release schedule to switch to the bundle
releases to get bugfixes out (i.e. committing to releases seem less of
a daunting thing) or the other way around if the fixed schedule turns
out to not work in an application's favor (I seem to recall Marble
having had some trouble with release prep).

(I do appreciate that this may also blur the line a bit too much given
we refer to the applications release as "The" KDE Applications
releases)

HS

Re: Applications Lifecycle Policy

[Kevin Ottens]

Hello,

On Tuesday, 4 July 2017 13:20:43 CEST Jonathan Riddell wrote:
> The applications lifecycle policy needs an update
> 
> Is this a good current state of it or are there more stages?
> 
> https://community.kde.org/Policies/Application_Lifecycle/Draft

Didn't we have cases of applications moving between KDE Applications and 
Extragear?

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.