Re: remove khelpcenter from next Plasma release?

[Sebastian Kügler]

Hi Yuri,

On Wednesday, March 09, 2016 06:37:09 PM Yuri Chornoivan wrote:
> Yes. That's what I meant.
> 
> But generally, I cannot say that I like the way the things are going. The  
> UserBase project does not have significant updates on applications pages  
> (although it was claimed that users are willing to write docs online),  
> there is a trend to sweep docs under the carpet, move them online, cut off  
> docs from applications, compile and package without docs, release without
> docs at all. That's not pretty and fair.
> 
> Sorry for being too rough. Please forgive me.

Being rough is fine, as long as you're also specific and constructive. You're 
not, so your being rough is just a useless rant, not something anybody can 
really work with.

How about you point out concrete problems and solutions for them? Most of us 
are not here for listening to rants, but want to actually improve something. 
Don't poison the atmosphere for those people.

The effect of your email (having written docs quite extensively in the past 
year) is that you're generalizing way too much, to the point I feel offended 
(and stupid for doing the unrecognized work in the first place).

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: remove khelpcenter from next Plasma release?

[R.Harish Navnit]

​Hi,​

On Wed, Mar 9, 2016 at 10:07 PM, Yuri Chornoivan  wrote:
>
>
> But generally, I cannot say that I like the way the things are going. The
UserBase project does not have significant updates on applications pages
(although it was claimed that users are willing to write docs online),
there is a trend to sweep docs under the carpet, move them online, cut off
docs from applications, compile and package without docs, release without
docs at all. That's not pretty and fair.
There was some reorganization of KDE's wikis done, earlier this month.[1]
We were at a sprint and we had just a week and had to target three wikis. I
can assure you, that of the three(community, techbase and userbase),
userbase needed the least tweaking. Largely because, the applications in
KF5 differ mostly in look and feel and fortunately, there hasn't been a
drastic change in the feature set. So a good number of articles over at
userbase still hold valid or can be considered useful, in someway. The same
can't be said of techbase, for instance and it needed(and probably, still
needs) some reworking.

Obviously, I haven't looked at whole of userbase and you might be able to
find cases where I am wrong. But having said that, I agree, that userbase
needs some love, but I don't think bringing that up in this thread is a
good idea. I strongly urge you to create a new thread to discuss this and
let's try to arrive at a solution.

​[1]
http://blogs.churlaud.com/somefoobar/2016/03/17/sprint-at-cern-things-got-done/
​

Thanks,
R.Harish Navnit
The Enigma 

Re: remove khelpcenter from next Plasma release?

[Marco Martin]

On Saturday 19 March 2016, Albert Astals Cid wrote:
> > 
> > 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.
> 

ok for us too..
something we need to do from our side?

-- 
Marco Martin

Re: remove khelpcenter from next Plasma release?

[Luigi Toscano]

On Thursday 17 of March 2016 11:54:31 Aaron Honeycutt wrote:
> 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!

Why use a different tool? KHelpCenter is (mostly) simply changing the release 
schedule...

-- 
Luigi

Re: 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

Re: 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 
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-de...@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

Re: 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

Re: remove khelpcenter from next Plasma release?

[Sebastian Kügler]

On Tuesday, March 15, 2016 05:52:55 PM Jeremy Whiting wrote:
> As an application developer I agree it makes sense to have khelpcenter
> released with KDE Applications. I also agree with Albert's point that
> having online documentation isn't the best since it could be newer
> than what's actually running. People using LTS distributions or
> "stable" variants of less often released distributions will have very
> old (to those of us that run from git) versions of stuff. Having
> online documentation for plasma 5.7 to look at while you're running
> plasma 4 would just confuse.

This can be solved, of course, by having versioned documentation online and 
point to that.

> Also, thanks Luigi for stepping up to maintain it.

+1
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: remove khelpcenter from next Plasma release?

[Albert Astals Cid]

El dimecres, 16 de març de 2016, a les 12:46:34 CET, Sebastian Kügler va 
escriure:
> On Tuesday, March 15, 2016 05:52:55 PM Jeremy Whiting wrote:
> > As an application developer I agree it makes sense to have khelpcenter
> > released with KDE Applications. I also agree with Albert's point that
> > having online documentation isn't the best since it could be newer
> > than what's actually running. People using LTS distributions or
> > "stable" variants of less often released distributions will have very
> > old (to those of us that run from git) versions of stuff. Having
> > online documentation for plasma 5.7 to look at while you're running
> > plasma 4 would just confuse.
> 
> This can be solved, of course, by having versioned documentation online and
> point to that.

Sure, but needs someone to develop and maintain that code, while a local 
KHelpCenter is something we already have developed and maintainer for ;)

Cheers,
  Albert

> 
> > Also, thanks Luigi for stepping up to maintain it.
> 
> +1

Re: remove khelpcenter from next Plasma release?

[Jeremy Whiting]

As an application developer I agree it makes sense to have khelpcenter
released with KDE Applications. I also agree with Albert's point that
having online documentation isn't the best since it could be newer
than what's actually running. People using LTS distributions or
"stable" variants of less often released distributions will have very
old (to those of us that run from git) versions of stuff. Having
online documentation for plasma 5.7 to look at while you're running
plasma 4 would just confuse.

Also, thanks Luigi for stepping up to maintain it.

BR,
Jeremy

On Tue, Mar 15, 2016 at 4:11 PM, Luigi Toscano  wrote:
> 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?
>
> Ciao
> --
> Luigi
> ___
> Plasma-devel mailing list
> plasma-de...@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

Re: remove khelpcenter from next Plasma release?

[Luigi Toscano]

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?

Ciao
-- 
Luigi

Re: remove khelpcenter from next Plasma release?

[Yuri Chornoivan]

написане Wed, 09 Mar 2016 18:24:59 +0200, Martin Klapetek  
:


On Wed, Mar 9, 2016 at 11:20 AM, Martin Gräßlin   
wrote:



Am 2016-03-09 16:43, schrieb Yuri Chornoivan:



Hi,

Just of curiosity, what is the next thing, after documentation (as
Plasma  almost does not have it), to get rid from Plasma? Is it
Okular, Krusader,  something else? Just to make simple, sleek and
unintrusive.

Thanks in advance for your answer.



Neither Okular, nor Krusader are part of Plasma. So what is that? Trying
to create a flamewar?

This is highly non-constructive, highly disrespectful towards the
developers caring about our user experience. This is absolutely not
acceptable.

Seriosuly pissed
Martin



I think there's a simple misunderstanding here.

Sebas meant removing the code from plasma repo in order to not having
to maintain the code as part of plasma-the-code while Yuri probably  
thought

this is about removing it from plasma-the-shell, ie. from kicker/kickoff
etc.

Cheers


Yes. That's what I meant.

But generally, I cannot say that I like the way the things are going. The  
UserBase project does not have significant updates on applications pages  
(although it was claimed that users are willing to write docs online),  
there is a trend to sweep docs under the carpet, move them online, cut off  
docs from applications, compile and package without docs, release without  
docs at all. That's not pretty and fair.


Sorry for being too rough. Please forgive me.

Best regards,
Yuri

Re: remove khelpcenter from next Plasma release?

[Yuri Chornoivan]

написане Wed, 09 Mar 2016 17:29:28 +0200, Sebastian Kügler :


Hi all,

[For the sake of sanity, please reply to both list, this topic affects
applications and Plasma.]

One of the topics we are discussing at the current Plasma sprint is  
whether we
really want khelpcenter as part of the Plasma releases in the future.  
Some

data points:

- khelpcenter is unmaintained, it has seen a rough port to KF5, but has
  otherwise seen zero love, this shows
- just dropping it would mean that the user gets sent to a webpage  
containing

  the latest version of the documentation, so khelpcenter's usecase is
  actually just being an offline cache, fallback mechanism are already  
in place

- said user documentation is spotty, this is only semi-related, but still
  doesn't exactly make a strong case for keeping it
- it uses KHTML

A casual poll among developers here at the sprint reveals that ~70% would
rather see it gone from Plasma, the rest abstains. Nobody from my  
(admittedly

small) sample really wants to keep it.

Killing it could mean that we remove it entirely (to unmaintained), or if
anybody is interested in maintaining it making it part of Applications,  
or

Extragear.

Let's seriously think about dropping it from Plasma 5.7 and onwards. If
anybody is hell-bent on keeping it, this person should consider  
maintaining it
as well. Unmaintained code in Plasma is not cool, and so far nobody  
seems to

care enough to step up.

Cheers,
--
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org



Hi,

Just of curiosity, what is the next thing, after documentation (as Plasma  
almost does not have it), to get rid from Plasma? Is it Okular, Krusader,  
something else? Just to make simple, sleek and unintrusive.


Thanks in advance for your answer.

Best regards,
Yuri

Re: remove khelpcenter from next Plasma release?

[Albert Astals Cid]

El Wednesday 09 March 2016, a les 15:29:28, Sebastian Kügler va escriure:
> Hi all,
> 
> [For the sake of sanity, please reply to both list, this topic affects
> applications and Plasma.]
> 
> One of the topics we are discussing at the current Plasma sprint is whether
> we really want khelpcenter as part of the Plasma releases in the future.
> Some data points:
> 
> - khelpcenter is unmaintained, it has seen a rough port to KF5, but has
>   otherwise seen zero love, this shows

https://github.com/KDE/khelpcenter/commits/master
shows some commits

> - just dropping it would mean that the user gets sent to a webpage
> containing the latest version of the documentation, so khelpcenter's
> usecase is actually just being an offline cache, fallback mechanism are
> already in place

Getting "the latest version of the documentation" may actually be a problem, 
you don't want to get the latest version of the documentation that speaks 
about features and buttons you don't see becaue your version doesn't have, you 
want to get the documentation for the version you are using.

> - it uses KHTML
I don't see why this is a problem, KHTML is enough for what khelpcenter needs.

> 
> A casual poll among developers here at the sprint reveals that ~70% would
> rather see it gone from Plasma, the rest abstains. Nobody from my
> (admittedly small) sample really wants to keep it.
> 
> Killing it could mean that we remove it entirely (to unmaintained), or if
> anybody is interested in maintaining it making it part of Applications, or
> Extragear.
> 
> Let's seriously think about dropping it from Plasma 5.7 and onwards. If
> anybody is hell-bent on keeping it, this person should consider maintaining
> it as well. Unmaintained code in Plasma is not cool, and so far nobody
> seems to care enough to step up.

As Okular maintainer, I disagree we should stop shipping khelpcenter, I want 
Okular users to be able to see the documentation without hitting the web.

If you want to move it from Plasma releases to KDE Applications releases, I 
think that's ok, it probably even makes more sense in there since in my 
opinion it is not really desktop related anyway.

Cheers,
  Albert

> 
> Cheers,

Re: remove khelpcenter from next Plasma release?

[Luigi Toscano]

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.

-- 
Luigi

Re: remove khelpcenter from next Plasma release?

[Sebastian Kügler]

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.

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.

Cheers,
--
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org

Re: remove khelpcenter from next Plasma release?

[Martin Klapetek]

On Wed, Mar 9, 2016 at 11:20 AM, Martin Gräßlin  wrote:

> Am 2016-03-09 16:43, schrieb Yuri Chornoivan:
>
>>
>> Hi,
>>
>> Just of curiosity, what is the next thing, after documentation (as
>> Plasma  almost does not have it), to get rid from Plasma? Is it
>> Okular, Krusader,  something else? Just to make simple, sleek and
>> unintrusive.
>>
>> Thanks in advance for your answer.
>>
>
> Neither Okular, nor Krusader are part of Plasma. So what is that? Trying
> to create a flamewar?
>
> This is highly non-constructive, highly disrespectful towards the
> developers caring about our user experience. This is absolutely not
> acceptable.
>
> Seriosuly pissed
> Martin
>

I think there's a simple misunderstanding here.

Sebas meant removing the code from plasma repo in order to not having
to maintain the code as part of plasma-the-code while Yuri probably thought
this is about removing it from plasma-the-shell, ie. from kicker/kickoff
etc.

Cheers
-- 
Martin Klapetek | KDE Developer

Re: remove khelpcenter from next Plasma release?

[Marco Martin]

On Wed, Mar 9, 2016 at 4:43 PM, Yuri Chornoivan  wrote:
> Hi,
>
> Just of curiosity, what is the next thing, after documentation (as Plasma
> almost does not have it), to get rid from Plasma? Is it Okular, Krusader,
> something else? Just to make simple, sleek and unintrusive.
>
> Thanks in advance for your answer.

None of those examples is part of the workspace (is like wondering if
Gwenview is part of K3b), they are excellent applications released on
their own, so the problem does not apply.

--
Marco Martin

Re: remove khelpcenter from next Plasma release?

[Martin Gräßlin]

Am 2016-03-09 16:43, schrieb Yuri Chornoivan:
написане Wed, 09 Mar 2016 17:29:28 +0200, Sebastian Kügler 
:



Hi all,

[For the sake of sanity, please reply to both list, this topic affects
applications and Plasma.]

One of the topics we are discussing at the current Plasma sprint is  
whether we
really want khelpcenter as part of the Plasma releases in the future.  
Some

data points:

- khelpcenter is unmaintained, it has seen a rough port to KF5, but 
has

  otherwise seen zero love, this shows
- just dropping it would mean that the user gets sent to a webpage  
containing

  the latest version of the documentation, so khelpcenter's usecase is
  actually just being an offline cache, fallback mechanism are already 
 in place
- said user documentation is spotty, this is only semi-related, but 
still

  doesn't exactly make a strong case for keeping it
- it uses KHTML

A casual poll among developers here at the sprint reveals that ~70% 
would
rather see it gone from Plasma, the rest abstains. Nobody from my  
(admittedly

small) sample really wants to keep it.

Killing it could mean that we remove it entirely (to unmaintained), or 
if
anybody is interested in maintaining it making it part of 
Applications,  or

Extragear.

Let's seriously think about dropping it from Plasma 5.7 and onwards. 
If
anybody is hell-bent on keeping it, this person should consider  
maintaining it
as well. Unmaintained code in Plasma is not cool, and so far nobody  
seems to

care enough to step up.

Cheers,
--
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org



Hi,

Just of curiosity, what is the next thing, after documentation (as
Plasma  almost does not have it), to get rid from Plasma? Is it
Okular, Krusader,  something else? Just to make simple, sleek and
unintrusive.

Thanks in advance for your answer.


Neither Okular, nor Krusader are part of Plasma. So what is that? Trying 
to create a flamewar?


This is highly non-constructive, highly disrespectful towards the 
developers caring about our user experience. This is absolutely not 
acceptable.


Seriosuly pissed
Martin

Re: remove khelpcenter from next Plasma release?

[Sebastian Kügler]

On Wednesday, March 09, 2016 17:43:37 Yuri Chornoivan wrote:
> Just of curiosity, what is the next thing, after documentation (as Plasma
> almost does not have it), to get rid from Plasma? Is it Okular, Krusader,
> something else? Just to make simple, sleek and unintrusive.
>
> Thanks in advance for your answer.

Yuri, this is an discussion between developers, and your email doesn't meet
the requirement of being constructive or respectful. Please change your
attitude or refrain from further commenting.

If you're unsure, read https://www.kde.org/code-of-conduct/
--
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org

Re: remove khelpcenter from next Plasma release?

[Sebastian Kügler]

On Wednesday, March 09, 2016 17:05:14 Luigi Toscano wrote:
> That said, I perceive this email as "khelpcenter is not welcome in Plasma",
> probably with a maintainer ("hell-bent on keeping it" sounds very negative
> to me). So not sure what should be the discussion about.

The discussion is about removing it from Plasma releases starting with 5.7,
see the subject of my email.

Let me cut right to the chase, do you want to maintain it? Does it need to be
in Plasma?

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

Sebastian Kügler|http://vizZzion.org| http://kde.org

Re: remove khelpcenter from next Plasma release?

[Marco Martin]

On Wed, Mar 9, 2016 at 5:05 PM, Luigi Toscano  wrote:
>
> There is a non-committed work to have search working again, which will cut the
> bug list. You should have probably already noticed a bunch of commits which
> fixes some language related issues.


thanks for stepping up in the maintainership of KHelpCenter

--
Marco Martin

Re: remove khelpcenter from next Plasma release?

[Luigi Toscano]

On Wednesday 09 of March 2016 15:29:28 Sebastian Kügler wrote:
> Hi all,
> 
> [For the sake of sanity, please reply to both list, this topic affects
> applications and Plasma.]
> 
> One of the topics we are discussing at the current Plasma sprint is whether
> we really want khelpcenter as part of the Plasma releases in the future.
> Some data points:
> 
> - khelpcenter is unmaintained, it has seen a rough port to KF5, but has
>   otherwise seen zero love, this shows
> - just dropping it would mean that the user gets sent to a webpage
> containing the latest version of the documentation, so khelpcenter's
> usecase is actually just being an offline cache, fallback mechanism are
> already in place 
> - said user documentation is spotty, this is only semi-related, but still 
doesn't exactly make a strong case for keeping it
> - it uses KHTML

There is a non-committed work to have search working again, which will cut the 
bug list. You should have probably already noticed a bunch of commits which 
fixes some language related issues.

Apart from that, I see a continued push to remove support for non-connected 
users. I still think that there is a value in that, but no one seems to agree 
with that.

Moreover, khelpcenter is not just for *our* documentation, but to access also 
other documentation on the system.

> A casual poll among developers here at the sprint reveals that ~70% would
> rather see it gone from Plasma, the rest abstains. Nobody from my
> (admittedly small) sample really wants to keep it.
> 
> Killing it could mean that we remove it entirely (to unmaintained), or if
> anybody is interested in maintaining it making it part of Applications, or
> Extragear.
> 
> Let's seriously think about dropping it from Plasma 5.7 and onwards. If
> anybody is hell-bent on keeping it, this person should consider maintaining
> it as well. Unmaintained code in Plasma is not cool, and so far nobody
> seems to care enough to step up.

That said, I perceive this email as "khelpcenter is not welcome in Plasma", 
probably with a maintainer ("hell-bent on keeping it" sounds very negative to 
me). So not sure what should be the discussion about.

Again, please recheck the recent list of commits.

Ciao
-- 
Luigi

remove khelpcenter from next Plasma release?

[Sebastian Kügler]

Hi all,

[For the sake of sanity, please reply to both list, this topic affects
applications and Plasma.]

One of the topics we are discussing at the current Plasma sprint is whether we
really want khelpcenter as part of the Plasma releases in the future. Some
data points:

- khelpcenter is unmaintained, it has seen a rough port to KF5, but has
  otherwise seen zero love, this shows
- just dropping it would mean that the user gets sent to a webpage containing
  the latest version of the documentation, so khelpcenter's usecase is
  actually just being an offline cache, fallback mechanism are already in place
- said user documentation is spotty, this is only semi-related, but still
  doesn't exactly make a strong case for keeping it
- it uses KHTML

A casual poll among developers here at the sprint reveals that ~70% would
rather see it gone from Plasma, the rest abstains. Nobody from my (admittedly
small) sample really wants to keep it.

Killing it could mean that we remove it entirely (to unmaintained), or if
anybody is interested in maintaining it making it part of Applications, or
Extragear.

Let's seriously think about dropping it from Plasma 5.7 and onwards. If
anybody is hell-bent on keeping it, this person should consider maintaining it
as well. Unmaintained code in Plasma is not cool, and so far nobody seems to
care enough to step up.

Cheers,
--
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org