Applications Lifecycle Policy

[Harald Sitter]

On Wed, Jul 5, 2017 at 7:01 AM, Christian Mollekopf
<chrigi_1 at fastmail.fm> 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