remove khelpcenter from next Plasma release?

[Albert Astals Cid]

El dijous, 17 de març de 2016, a les 0:18:53 CET, Luigi Toscano va escriure:
> Luigi Toscano ha scritto:
> > Luigi Toscano ha scritto:
> >> On Wednesday 09 of March 2016 16:50:39 Sebastian Kügler wrote:
> >>> On Wednesday, March 09, 2016 17:30:01 Luigi Toscano wrote:
> >>>>> Let me cut right to the chase, do you want to maintain it? Does it
> >>>>> need
> >>>>> to
> >>>>> be in Plasma?
> >>>> 
> >>>> Yes, I can maintain it. In fact many features come from components I
> >>>> already  control.
> >>>> 
> >>>>> You're right that Plasma devs don't seem to want it, I thought my
> >>>>> initial
> >>>>> email made that pretty clear. We do think that disconnected systems
> >>>>> are
> >>>>> rather a fringe case, and that our time and effort is better spent on
> >>>>> other
> >>>>> things.
> >>>> 
> >>>> Then the question still holds: with a maintainer, does it have a place
> >>>> in
> >>>> Plasma? I'm not talking about an hypothetical time and effort for
> >>>> maintaining  this offline use case (which will continue to be 0) but in
> >>>> the
> >>>> light of the statement above. In other words, if the question mark in
> >>>> the
> >>>> subject is real or rhetorical.
> >>>> I'm ready for both possible outcomes.
> >>> 
> >>> Ah OK, sorry for misunderstanding it.
> >>> 
> >>> I think there are the following options:
> >>> 
> >>> 1) keeping it in Plasma with maintainer
> >>> 2) keeping it outside of Plasma with maintainer
> >>> 3) moving it to unmaintained (that's basically killing it)
> >>> 4) keeping the status quo (not wanted)
> >>> 
> >>> My personal preference would be an optional component (hence Extragear),
> >>> since I think that the vast majority of users has web access, so
> >>> khelpcenter isn't necessary and only adds to our maintainance burden
> >>> without much gain in those cases.
> >> 
> >> My offer stands and we can rule out 4) and 3).
> >> Note that 2) could also mean a move to Applications (from your point of
> >> view it does not matter too much).
> >> The case 1) shouldn't add maintenance anyway as the maintainer is
> >> identified.>> 
> >>> If we can move from 4) to 1) (so status quo but with maintainer), that
> >>> would already be an improvement of course.
> >>> 
> >>> The question mark was honest, we haven't made a decision on it, but
> >>> different people do have expressed a preference for not shipping it (as
> >>> or
> >>> by default in Plasma releases). We may have missed important points, and
> >>> we
> >>> don't want to just kick things out unilaterally.
> >> 
> >> I think we can leave some time for other people to comment. The shortest
> >> deadline of all possibilities is the one for moving into Applications,
> >> and
> >> there are still 8 days before the dependency freeze and two weeks before
> >> the branch.
> > 
> > Any other comment from anyone else?
> 
> I think I made up my mind. If no one else objects further, I officially ask
> the release team (in CC) if it is possible to accept khelpcenter as part of
> Applications for the upcoming release 16.04, module "applications". No
> dependency changes are planned for the current master branch khelpcenter for
> now.
> 
> We will have a bit of overlap for a while (khelpcenter/Plasma5.6 vs
> khelpcenter/Applications16.04), but the version number from Applications is
> higher, so it shouldn't be a problem for packagers (they already handled the
> more complicated khelpcenter/kde-runtime vs khelpcenter/Plasma).
> 
> If this is accepted, I will manage the various tickets with sysadmins (and
> at least move the translations myself).

No objections from my side, please get a decision+moved tuesday the latest.

Cheers,
  Albert

> 
> Ciao