remove khelpcenter from next Plasma release?

[Luigi Toscano]

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