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.