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