remove khelpcenter from next Plasma release?

[Aaron Honeycutt]

Kubuntu uses it for our Documentation but our current tools do have a PDF
export option as well as epub so we could use a different tool to read
those files without khelpcenter. I do thank every developer for his/her
work and current work on that package!

On Wed, Mar 16, 2016 at 7:19 PM Luigi Toscano <luigi.toscano at tiscali.it>
wrote:

> 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).
>
> Ciao
> --
> Luigi
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20160317/d16b1347/attachment.html>