Applications Lifecycle Policy

[Christian Mollekopf]

I'm just going to reply to luigis mail since the others make similar
arguments.

On Wed, Jul 5, 2017, at 12:16 AM, Luigi Toscano wrote:
> 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:
> > 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.
> 

Yes, that's basically the difference between the approaches.


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

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.

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

I'm happy since I can release from extragear. If I couldn't (apart from
the argument that it doesn't make sense due to lack of feedback, just
from the upfront effort), I'm not sure where those repositories would be
now. No hurdle is insurmountable or even very large, but everyone has
plenty to do without any of them, so if there is an easier way it's just
very tempting to just pick that.

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

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.

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.

Cheers,
Christian