Re: Rebase of kopete branch and push it to master

[Pali Rohár]

On Tuesday 16 January 2018 00:32:44 Albert Astals Cid wrote:
> El dimarts, 16 de gener de 2018, a les 0:09:50 CET, Pali Rohár va escriure:
> > On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote:
> > > So is the problem:
> > >  a) that you could not push that master-kf5 to master
> > 
> > Problem is really a).
> 
> Why is that? You said master-kf5 is just a rebase of kf5 on top of master, 
> what's the problem of pushing that branch?

Because it does not work.

remote: Push declined - excessive notifications would be sent
remote: Please file a KDE Sysadmin bug to continue

Therefore I opened sysadmin ticket T7642 and I was told that I should
discuss about it on kde-core-devel.

-- 
Pali Rohár
pali.ro...@gmail.com

Re: Rebase of kopete branch and push it to master

[Albert Astals Cid]

El dimarts, 16 de gener de 2018, a les 0:09:50 CET, Pali Rohár va escriure:
> On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote:
> > So is the problem:
> >  a) that you could not push that master-kf5 to master
> 
> Problem is really a).

Why is that? You said master-kf5 is just a rebase of kf5 on top of master, 
what's the problem of pushing that branch?

Cheers,
  Albert

Re: Rebase of kopete branch and push it to master

[Luigi Toscano]

Pali Rohár ha scritto:
> On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote:
>> So is the problem:
>>  a) that you could not push that master-kf5 to master
> 
> Problem is really a).
> 

a) can't be changed.
You can merge your rebased kf5 branch to master. I would still complain,
because the rebase kf5 would have a messed-up history, but if it's fine for
the other people, well...

-- 
Luigi

Re: Rebase of kopete branch and push it to master

[Pali Rohár]

On Tuesday 16 January 2018 00:06:29 Albert Astals Cid wrote:
> So is the problem:
>  a) that you could not push that master-kf5 to master

Problem is really a).

-- 
Pali Rohár
pali.ro...@gmail.com

Re: Rebase of kopete branch and push it to master

[Albert Astals Cid]

El dilluns, 15 de gener de 2018, a les 9:50:11 CET, Pali Rohár va escriure:
> On Sunday 14 January 2018 23:59:45 Albert Astals Cid wrote:
> > El diumenge, 14 de gener de 2018, a les 21:52:29 CET, Pali Rohár va 
escriure:
> > > Hi!
> > 
> > Hello Mr Rohár
> > 
> > > From the following ticket https://phabricator.kde.org/T7642 I was
> > > suggested to open discussion on kde-core-devel list. Sending this email
> > > also to kopete-devel as it is relevant for Kopete development.
> > > 
> > > Currently in Kopete git repository https://cgit.kde.org/kopete.git/ is a
> > > branch kf5 which contains port of Kopete to KF5. That branch was created
> > > 3 years ago as part of GSoC was used as "staging area". Some patches
> > > there are incomplete and later were "fixed & cherry-picked" into master
> > > branch. Therefore you can find commits with same description/commit
> > > message in master branch and kf5, but correct (working) one is in
> > > master. Later this branch was used for pushing whole work of porting.
> > > 
> > > I took commits from this branch kf5 and rebased it on top of master with
> > > cleanup of duplicate commits and commits which are already in master
> > > branch. And this rebase I pushed into my cloned git repository
> > > https://cgit.kde.org/clones/kopete/pali/kopete.git/log/?h=master-kf5
> > > 
> > > I wanted to push these master-kf5 changes into main kopete repository
> > > into master branch, but it was rejected by commits hook, see above T7642
> > > ticket.
> > 
> > No, we can't read private sysadmin tickets.
> > 
> > > Reason is that "rebase" is not supported by KDE. ltoscano and
> > > bcooksley suggested to discuss about it on kde-core-devel.
> > > 
> > > From my side as that branch kf5 contains duplicate commits as in master
> > > branch and commits with same commit messages and different (old) patches
> > > I really do not like see these commits in master branch. It would break
> > > certain of git functionality (like bisect or blame, or log). And because
> > > it was mean as a staging area, I would really like to use that rebase
> > > for this time. I do not thing that there are advantage to merge this kf5
> > > branch as is into master and better would be rebase.
> > > 
> > > Is there anything really against rebasing this one particular branch?
> > 
> > Yes, you have not explained why you need rebasing.
> 
> I already wrote it. I do not want to see one commit in git history
> accessible from master branch two times. Or git commits with same commit
> message / same description, but with different content.

That's not really a big problem is it? Like you wrote it seemed that if you 
were unable to rebase things would be terribly broken or something.

> 
> > Just merge master-kf5 into master.
> > 
> > master as it is right now works, no?
> 
> Yes, but depends on KDE4.
> 
> > (or i hope it should, we agreed long time
> > ago to not break master), so just merge the "kf5 clean branch" into it and
> > that's it, no?
> > 
> > > For future (to prevent any such problem with rebasing), staging areas
> > > would be outside of main KDE git repository.
> > 
> > How would that fix anything? You will still not be able to rebase master.
> 
> But I never wanted such thing, nor I want in the future.

I am really lost then, you don't want to rebase master, but you wrote an email 
saying you needed to rebase the master branch, no? If not then i misunderstood 
your problem.

> > Or you're saying that you want to rebase your work branches?
> 
> Yes, take branch kf5, locally rebase it (on top of master) and then push
> changes to remote master. As already wrote, I did it and pushed this
> rebased branch into my cloned git repository under branch name
> master-kf5.

So is the problem:
 a) that you could not push that master-kf5 to master
or
 b) that you could not push that master-kf5 to kf5
or
 c) something else and Albert is still lost
?

Cheers,
  Albert

Importing kdiff3 - was - Re: Aw: Re: KDE inclusion

[Albert Astals Cid]

El dimarts, 9 de gener de 2018, a les 20:06:36 CET, Michael Reeves va 
escriure:
> I have a version of kdiff3 that I ported to kf5. I like to what build
> requirements kf5 as a whole has. Also what would be the process for being
> considered for inclusion in kde?

So now that we have Joachim's blessing to use the name, the process is 
basically outlined at https://community.kde.org/Incubator/Incubation_Process 
but it's basically importing the project into our git and then making sure it 
generally follows our rules & procedures.

I understand you want to continue maintaining the new kdiff3 and you are not 
just "dumping it" into us, right?

Cheers,
  Albert

El divendres, 12 de gener de 2018, a les 1:21:02 CET, Joachim Eibl va 
escriure:
> Hi,

> You have my blessing to use the name KDiff3.

Re: Aw: Re: KDE inclusion

[Michael Reeves]

Just a not in the at vs. kde. The ported to hf5/qt5 eliminated some of the
code differences between the two. I removed to if defs as obsolete. A third
I replaced with a platform check for Windows as there seems no other need
for it now. I don't have a preference on this.

On Jan 15, 2018 3:09 AM, "Valentin Rusu"  wrote:

* Joachim Eibl  [2018-01-12 01:21:02 +0100]:

> I had a try at it myself, but was quite overwhelmed about the big
changes in KF5.
>
> 
>
> You have my blessing to use the name KDiff3.
>

Great news for a very useful tool! After having ported it to KDE4, I was
also overwhelmed by the changes for KF5. Today I'm unfortunately forced
to use the Qt version. Perhaps we should stick with that version and
simply have it hosted and maintained as a KDE extragear project.

--
Valentin Rusu
IRC: valir

Re: KDE and Google Summer of Code 2018

[Nate Graham]

I've submitted an idea for System Settings: Improve handling for 
touchpads and mice with Libinput


https://community.kde.org/GSoC/2018/Ideas#Improve_handling_for_touchpads_and_mice_with_Libinput

This is pretty important going forward since most distros are shipping 
with Libinput now, but our users aren't able to configure their devices 
without resorting to editing xorg config files using a different driver.


Nate


On 01/15/2018 06:13 AM, Dmitry Kazakov wrote:

Hi, Valorie!

I have just edited the list of Krita ideas, now we have 8 ideas, 4 of 
which are low-hanging fruits with localized optimizations of the code. I 
hope that will help people who do not want to learn all half-million 
lines of Krita code.


Speaking truly, I think I understand why there is so little effort from 
people with the ideas. Since the last year Google forbids students to 
apply more than 2 times, it means that most of the applicants will be 
newcomers and, most probably, they will not be able to prepare some 
extensive proposal/design for a project. It is just too difficult to 
prepare a good proposal for a project so big in size. So it might be 
that the quality of last year proposals discouraged people from doing 
this work again.


The only way how we can solve the issue is to prepare very scope-limited 
tasks, such that the students would not need to learn all the code (in 
our case we just added AVX optimizations, which are limited to a scope 
of a couple of classes). But that is not always possible or makes sense 
for the some projects.



On 15.01.2018 03:39, Valorie Zimmerman wrote:
I'm very discouraged to see so little movement on this. After skipping 
GCi this past fall, are we now also considering skipping GSoC? Or 
downsizing the number of students we are mentoring?


Without Ideas we will not get students. More important, we must 
complete the Org application soon, and the Ideas page is the core of 
that application.


This is good for your team and your project, in the long run. It 
brings in new contributors and fresh ideas.


If you need some guidance, please read 
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html


I should have linked to it for the last email.

Valorie

On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman 
> wrote:



Hello GSoC mentors, and teams supporting mentors,

TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas
; read
https://community.kde.org/GSoC. Now.

Every year, we've asked for more time to get ramped up for GSoC,
and so now is the time for organizations to apply[1]. We have
begun to write our application, and  that means that our Ideas
page needs to be filled NOW, because that is the prime
consideration for the GSoC team once the Org Applications deadline
has passed.

The quality of our ideas and the guidance they give our students
are the most important part of our application. Please begin
filling in your ideas now if you have not already, and ensure that
that page is comprehensive, accurate and attractive. Including
screenshots and other images is allowed, if it enriches the idea
for a project. *Please ensure complete information about how to
contact the team*; this is crucial.

Also, take a look at the landing page
https://community.kde.org/GSoC. Experienced mentors agree that:

1. commits must be made before the student proposal is submitted,
and linked on that proposal, and

2. that regular communication from the student must be initiated
by the student at least weekly, and we expect daily or nearly
daily communication with the team in a more informal way.

Be sure to point students to that information, as this should
lower the number of proposals, while raising the quality.

1. https://developers.google.com/open-source/gsoc/timeline


PS: If your team has an Idea, ensure that you have mentors for it,
and that those mentors are subscribe to KDE-Soc-Mentor list.
Remove any ideas without mentors available, please. Now, before
you forget!

Valorie



--
http://about.me/valoriez


--
Dmitry Kazakov

Re: KDE and Google Summer of Code 2018

[Dmitry Kazakov]

Hi, Valorie!

I have just edited the list of Krita ideas, now we have 8 ideas, 4 of 
which are low-hanging fruits with localized optimizations of the code. I 
hope that will help people who do not want to learn all half-million 
lines of Krita code.


Speaking truly, I think I understand why there is so little effort from 
people with the ideas. Since the last year Google forbids students to 
apply more than 2 times, it means that most of the applicants will be 
newcomers and, most probably, they will not be able to prepare some 
extensive proposal/design for a project. It is just too difficult to 
prepare a good proposal for a project so big in size. So it might be 
that the quality of last year proposals discouraged people from doing 
this work again.


The only way how we can solve the issue is to prepare very scope-limited 
tasks, such that the students would not need to learn all the code (in 
our case we just added AVX optimizations, which are limited to a scope 
of a couple of classes). But that is not always possible or makes sense 
for the some projects.



On 15.01.2018 03:39, Valorie Zimmerman wrote:
I'm very discouraged to see so little movement on this. After skipping 
GCi this past fall, are we now also considering skipping GSoC? Or 
downsizing the number of students we are mentoring?


Without Ideas we will not get students. More important, we must 
complete the Org application soon, and the Ideas page is the core of 
that application.


This is good for your team and your project, in the long run. It 
brings in new contributors and fresh ideas.


If you need some guidance, please read 
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html


I should have linked to it for the last email.

Valorie

On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman 
> wrote:



Hello GSoC mentors, and teams supporting mentors,

TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas
; read
https://community.kde.org/GSoC. Now.

Every year, we've asked for more time to get ramped up for GSoC,
and so now is the time for organizations to apply[1]. We have
begun to write our application, and  that means that our Ideas
page needs to be filled NOW, because that is the prime
consideration for the GSoC team once the Org Applications deadline
has passed.

The quality of our ideas and the guidance they give our students
are the most important part of our application. Please begin
filling in your ideas now if you have not already, and ensure that
that page is comprehensive, accurate and attractive. Including
screenshots and other images is allowed, if it enriches the idea
for a project. *Please ensure complete information about how to
contact the team*; this is crucial.

Also, take a look at the landing page
https://community.kde.org/GSoC. Experienced mentors agree that:

1. commits must be made before the student proposal is submitted,
and linked on that proposal, and

2. that regular communication from the student must be initiated
by the student at least weekly, and we expect daily or nearly
daily communication with the team in a more informal way.

Be sure to point students to that information, as this should
lower the number of proposals, while raising the quality.

1. https://developers.google.com/open-source/gsoc/timeline


PS: If your team has an Idea, ensure that you have mentors for it,
and that those mentors are subscribe to KDE-Soc-Mentor list.
Remove any ideas without mentors available, please. Now, before
you forget!

Valorie



--
http://about.me/valoriez


--
Dmitry Kazakov

Re: plasma-active-window-control - was -Re: 2 New Plasmoids in Kdereview

[Albert Astals Cid]

El dilluns, 15 de gener de 2018, a les 0:15:59 CET, Martin Kostolný va 
escriure:
> You are right, integration of global-menu functionality is copied from
> appmenu widget code. It is also mentioned in
> plasma-active-window-control/plugin/README.
> 
> I consider it a temporary solution before a proper appmenu datasource is
> introduced. David Edmundson wrote a while ago that the datasource is on the
> way but it needs polishing and that I could look into that. I didn't yet
> have enough time to look it up and dive in but I intend to.
> 
> In the meantime I use the copied code. Is it possible to use the existing
> code without copying? Of course I can prepare a script that would
> automatically copy it from another repo (plasma-workspace) and patch it but
> it seems a bit hacky. I also don't know how would I integrate it in cmake
> including making it work in KDE CI. Should I try to do that? Also there is
> (I believe) no way to use a private plugin of a different widget.

Nah, don't do that, if you *promise* a solution is in the works and you'll 
help with it i guess that's enough.

Any script or other solution will be a pain.

Cheers,
  Albert

> 
> Is there another way to solve this problem?
> 
> Thanks!
> Martin
> 
> PS: It seems my mails to kde-core-devel have sometimes delays more then 1
> day before they actually arrive to the archives. Is it normal or there is a
> problem on my side?
> On neděle 14. ledna 2018 23:47:53 CET Albert Astals Cid wrote:
> > El dissabte, 13 de gener de 2018, a les 10:46:01 CET, Martin Kostolný va
> > 
> > escriure:
> > > 2) On the other hand plasma-active-window-control could be part of
> > > kdeplasma-addons because it is multiplatform, has C++ plugin and uses
> > > e.g.
> > > TaskManager module of Plasma which changes from time to time. So it
> > > would
> > > be nice to release always compatible version of this widget.
> > 
> > There seems to be lots of copied code in here.
> > 
> > Why?
> > 
> > Cheers,
> > 
> >   Albert

Re: Aw: Re: KDE inclusion

[Albert Astals Cid]

El diumenge, 14 de gener de 2018, a les 12:10:07 CET, Valentin Rusu va 
escriure:
> * Joachim Eibl  [2018-01-12 01:21:02 +0100]:
> > I had a try at it myself, but was quite overwhelmed about the big
> > changes in KF5.
> > 
> > 
> > 
> > You have my blessing to use the name KDiff3.
> 
> Great news for a very useful tool! After having ported it to KDE4, I was
> also overwhelmed by the changes for KF5. Today I'm unfortunately forced
> to use the Qt version. Perhaps we should stick with that version and
> simply have it hosted and maintained as a KDE extragear project.

Or maybe we should do what the person that did the work thinks its a better 
idea :)

Cheers,
  Albert

Re: KDE and Google Summer of Code 2018

[Johnny Jazeix]

Hi,

on GCompris side, we hope/plan to mentor 2 students like last year. I
updated the page to add one more task.

Regarding the events: this year, we were planning to skip SoK to focus more
on GCi and GSoC, having the 3 events is too consuming and do not allow us
to progress on our main tasks. There was a bit of change due to the fact
that it was GCi that was skipped but the main point is still there, we
don't have enough time/resource to handle the 3 events.

Johnny


2018-01-15 1:39 GMT+01:00 Valorie Zimmerman :

> I'm very discouraged to see so little movement on this. After skipping GCi
> this past fall, are we now also considering skipping GSoC? Or downsizing
> the number of students we are mentoring?
>
> Without Ideas we will not get students. More important, we must complete
> the Org application soon, and the Ideas page is the core of that
> application.
>
> This is good for your team and your project, in the long run. It brings in
> new contributors and fresh ideas.
>
> If you need some guidance, please read https://google.github.io/
> gsocguides/mentor/defining-a-project-ideas-list.html
>
> I should have linked to it for the last email.
>
> Valorie
>
> On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman <
> valorie.zimmer...@gmail.com> wrote:
>
>>
>> Hello GSoC mentors, and teams supporting mentors,
>>
>> TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas; read
>> https://community.kde.org/GSoC. Now.
>>
>> Every year, we've asked for more time to get ramped up for GSoC, and so
>> now is the time for organizations to apply[1]. We have begun to write our
>> application, and  that means that our Ideas page needs to be filled NOW,
>> because that is the prime consideration for the GSoC team once the Org
>> Applications deadline has passed.
>>
>> The quality of our ideas and the guidance they give our students are the
>> most important part of our application. Please begin filling in your ideas
>> now if you have not already, and ensure that that page is comprehensive,
>> accurate and attractive. Including screenshots and other images is allowed,
>> if it enriches the idea for a project. *Please ensure complete information
>> about how to contact the team*; this is crucial.
>>
>> Also, take a look at the landing page https://community.kde.org/GSoC.
>> Experienced mentors agree that:
>>
>> 1. commits must be made before the student proposal is submitted, and
>> linked on that proposal, and
>>
>> 2. that regular communication from the student must be initiated by the
>> student at least weekly, and we expect daily or nearly daily communication
>> with the team in a more informal way.
>>
>> Be sure to point students to that information, as this should lower the
>> number of proposals, while raising the quality.
>>
>> 1. https://developers.google.com/open-source/gsoc/timeline
>>
>> PS: If your team has an Idea, ensure that you have mentors for it, and
>> that those mentors are subscribe to KDE-Soc-Mentor list. Remove any ideas
>> without mentors available, please. Now, before you forget!
>>
>> Valorie
>>
>
>
> --
> http://about.me/valoriez
>

Re: Rebase of kopete branch and push it to master

[Pali Rohár]

On Sunday 14 January 2018 23:59:45 Albert Astals Cid wrote:
> El diumenge, 14 de gener de 2018, a les 21:52:29 CET, Pali Rohár va escriure:
> > Hi!
> 
> Hello Mr Rohár
> 
> > 
> > From the following ticket https://phabricator.kde.org/T7642 I was
> > suggested to open discussion on kde-core-devel list. Sending this email
> > also to kopete-devel as it is relevant for Kopete development.
> > 
> > Currently in Kopete git repository https://cgit.kde.org/kopete.git/ is a
> > branch kf5 which contains port of Kopete to KF5. That branch was created
> > 3 years ago as part of GSoC was used as "staging area". Some patches
> > there are incomplete and later were "fixed & cherry-picked" into master
> > branch. Therefore you can find commits with same description/commit
> > message in master branch and kf5, but correct (working) one is in
> > master. Later this branch was used for pushing whole work of porting.
> > 
> > I took commits from this branch kf5 and rebased it on top of master with
> > cleanup of duplicate commits and commits which are already in master
> > branch. And this rebase I pushed into my cloned git repository
> > https://cgit.kde.org/clones/kopete/pali/kopete.git/log/?h=master-kf5
> > 
> > I wanted to push these master-kf5 changes into main kopete repository
> > into master branch, but it was rejected by commits hook, see above T7642
> > ticket. 
> 
> No, we can't read private sysadmin tickets.
> 
> > Reason is that "rebase" is not supported by KDE. ltoscano and
> > bcooksley suggested to discuss about it on kde-core-devel.
> > 
> > From my side as that branch kf5 contains duplicate commits as in master
> > branch and commits with same commit messages and different (old) patches
> > I really do not like see these commits in master branch. It would break
> > certain of git functionality (like bisect or blame, or log). And because
> > it was mean as a staging area, I would really like to use that rebase
> > for this time. I do not thing that there are advantage to merge this kf5
> > branch as is into master and better would be rebase.
> > 
> > Is there anything really against rebasing this one particular branch?
> 
> Yes, you have not explained why you need rebasing. 

I already wrote it. I do not want to see one commit in git history
accessible from master branch two times. Or git commits with same commit
message / same description, but with different content.

> Just merge master-kf5 into master.
> 
> master as it is right now works, no?

Yes, but depends on KDE4.

> (or i hope it should, we agreed long time 
> ago to not break master), so just merge the "kf5 clean branch" into it and 
> that's it, no?
> 
> > For future (to prevent any such problem with rebasing), staging areas
> > would be outside of main KDE git repository.
> 
> How would that fix anything? You will still not be able to rebase master.

But I never wanted such thing, nor I want in the future.

> Or you're saying that you want to rebase your work branches?

Yes, take branch kf5, locally rebase it (on top of master) and then push
changes to remote master. As already wrote, I did it and pushed this
rebased branch into my cloned git repository under branch name
master-kf5.

> > But for now I would like to have finally KF5 port in master branch.
> > 
> > I'm very disappointed by KDE as I'm periodically hitting technical
> > problems with KDE infrastructure which makes maintaining of Kopete
> > application just harder. 
> 
> Now that you mention it, I'm very disappointed that you never answered my 
> answer to your email 
> https://mail.kde.org/pipermail/release-team/2017-November/010714.html
> 
> > (Problems like git push is not reflected to
> > annongit servers, git push hooks are failing because of dns server
> > errors and now git push failed because rebase is not supported). When I
> > compare it with other servers (like Launchpad, Github or old Gitorious)
> > I never hit any problem on them (yet).
> 
> I've never hit any of the problems you mention with KDE servers either.
> 
> Best Regards,
>   Albert
> 
> > 
> > I'm not subscribed to kde-core-devel, so please CC me on reply.
> 
> 

-- 
Pali Rohár
pali.ro...@gmail.com

Re: 2 New Plasmoids in Kdereview

[Ben Cooksley]

On Fri, Jan 12, 2018 at 11:53 AM, Martin Kostolný  wrote:
> Hi Ben, Ingo,

Hi Martin,

>
> that is right, the previous mail (from yesterday's night) was my first mail 
> to kde-core-devel, which was done based on mentioned point 3 under kdereview 
> section.
>
> The reason I did that after this long was actually I wasn't sure what to do 
> (to pass incubation/review) after my projects were imported to KDE 
> repositories. That is entirely my fault of course. Also, I had then less time 
> so I put that aside.

Sorry about that, we should have provided clearer guidance on the process here.

>
> Anyway now I'm back, have time :) and I'm ready to answer any questions and 
> fix issues with my projects.
>
> Expected project destinations:
> 1) I'd like plasma-redshift-control to be an extragear project with own 
> versioning. This is because redshift is only for Xorg platform and there is 
> no need to tie it with Plasma versioning.
>
> 2) On the other hand plasma-active-window-control could be part of 
> kdeplasma-addons because it is multiplatform, has C++ plugin and uses e.g. 
> TaskManager module of Plasma which changes from time to time. So it would be 
> nice to release always compatible version of this widget.
>
> These are just propositions, of course.
>
> I suspect it is not yet time for me to file a sysadmin ticket, but if it is, 
> please let me know :).

Thanks for that detail, and for starting the separate threads for
each. In about 2 weeks time please file Sysadmin tickets and we can
get both moved to Extragear, and from there look towards making first
releases of both.

>
> Thank You,
> Martin

Cheers,
Ben

>
>
> On Thursday, 11 January 2018 23:18:38 CET Ingo Klöcker wrote:
>> On Donnerstag, 11. Januar 2018 21:10:51 CET Ben Cooksley wrote:
>> > On Thu, Jan 11, 2018 at 1:15 PM, Martin Kostolný 
>> wrote:
>> > > I'd like to move forward with my new plasmoid projects that landed in
>> > > kdereview some time ago.
>> > >
>> > > https://phabricator.kde.org/source/plasma-redshift-control/
>> > > https://phabricator.kde.org/source/plasma-active-window-control/
>> >
>> > Given that the review period has long since passed I think we can
>> > safely say that these two applets can move to their final place from
>> > KDE Review.
>>
>> I don't think that Martin has emailed "kde-core-devel and other relevant
>> mailing lists with details of your project and what the expected destination
>> is for the repo" which is point 3 under kdereview on
>> https://community.kde.org/Policies/Application_Lifecycle
>>
>> Therefore, I think the review period did not actually start yet. Or have the
>> projects already been reviewed elsewhere, e.g. on the plasma ml?
>>
>>
>> Regards,
>> Ingo
>
>
>
>
>

Re: plasma-active-window-control - was -Re: 2 New Plasmoids in Kdereview

[Ben Cooksley]

On Mon, Jan 15, 2018 at 12:15 PM, Martin Kostolný  wrote:
> You are right, integration of global-menu functionality is copied from 
> appmenu widget code. It is also mentioned in 
> plasma-active-window-control/plugin/README.

Hi Martin,

>
> I consider it a temporary solution before a proper appmenu datasource is 
> introduced. David Edmundson wrote a while ago that the datasource is on the 
> way but it needs polishing and that I could look into that. I didn't yet have 
> enough time to look it up and dive in but I intend to.
>
> In the meantime I use the copied code. Is it possible to use the existing 
> code without copying? Of course I can prepare a script that would 
> automatically copy it from another repo (plasma-workspace) and patch it but 
> it seems a bit hacky. I also don't know how would I integrate it in cmake 
> including making it work in KDE CI. Should I try to do that? Also there is (I 
> believe) no way to use a private plugin of a different widget.
>
> Is there another way to solve this problem?
>
> Thanks!
> Martin
>
> PS: It seems my mails to kde-core-devel have sometimes delays more then 1 day 
> before they actually arrive to the archives. Is it normal or there is a 
> problem on my side?

I've now moderated the mailing list queue, and it seems there were a
few messages stuck in there waiting for approval.
This is fairly normal for kde-core-devel, which is a moderated list.

In terms of enabling CI, please file a Sysadmin ticket and we can
arrange this fairly easily.

Cheers,
Ben


>
>
> On neděle 14. ledna 2018 23:47:53 CET Albert Astals Cid wrote:
>> El dissabte, 13 de gener de 2018, a les 10:46:01 CET, Martin Kostolný va
>> escriure:
>> > 2) On the other hand plasma-active-window-control could be part of
>> > kdeplasma-addons because it is multiplatform, has C++ plugin and uses e.g.
>> > TaskManager module of Plasma which changes from time to time. So it would
>> > be nice to release always compatible version of this widget.
>>
>> There seems to be lots of copied code in here.
>>
>> Why?
>>
>> Cheers,
>>   Albert
>
>
>
>
>

Re: plasma-active-window-control - was -Re: 2 New Plasmoids in Kdereview

[Martin Kostolný]

You are right, integration of global-menu functionality is copied from appmenu 
widget code. It is also mentioned in plasma-active-window-control/plugin/README.

I consider it a temporary solution before a proper appmenu datasource is 
introduced. David Edmundson wrote a while ago that the datasource is on the way 
but it needs polishing and that I could look into that. I didn't yet have 
enough time to look it up and dive in but I intend to.

In the meantime I use the copied code. Is it possible to use the existing code 
without copying? Of course I can prepare a script that would automatically copy 
it from another repo (plasma-workspace) and patch it but it seems a bit hacky. 
I also don't know how would I integrate it in cmake including making it work in 
KDE CI. Should I try to do that? Also there is (I believe) no way to use a 
private plugin of a different widget.

Is there another way to solve this problem?

Thanks!
Martin

PS: It seems my mails to kde-core-devel have sometimes delays more then 1 day 
before they actually arrive to the archives. Is it normal or there is a problem 
on my side?


On neděle 14. ledna 2018 23:47:53 CET Albert Astals Cid wrote:
> El dissabte, 13 de gener de 2018, a les 10:46:01 CET, Martin Kostolný va 
> escriure:
> > 2) On the other hand plasma-active-window-control could be part of
> > kdeplasma-addons because it is multiplatform, has C++ plugin and uses e.g.
> > TaskManager module of Plasma which changes from time to time. So it would
> > be nice to release always compatible version of this widget.
> 
> There seems to be lots of copied code in here.
> 
> Why?
> 
> Cheers,
>   Albert

Re: Aw: Re: KDE inclusion

[Valentin Rusu]

* Joachim Eibl  [2018-01-12 01:21:02 +0100]:

> I had a try at it myself, but was quite overwhelmed about the big 
> changes in KF5.
> 
> 
> 
> You have my blessing to use the name KDiff3.
> 

Great news for a very useful tool! After having ported it to KDE4, I was
also overwhelmed by the changes for KF5. Today I'm unfortunately forced
to use the Qt version. Perhaps we should stick with that version and
simply have it hosted and maintained as a KDE extragear project.

-- 
Valentin Rusu
IRC: valir

Re: KDE and Google Summer of Code 2018

[Valorie Zimmerman]

I'm very discouraged to see so little movement on this. After skipping GCi
this past fall, are we now also considering skipping GSoC? Or downsizing
the number of students we are mentoring?

Without Ideas we will not get students. More important, we must complete
the Org application soon, and the Ideas page is the core of that
application.

This is good for your team and your project, in the long run. It brings in
new contributors and fresh ideas.

If you need some guidance, please read
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html

I should have linked to it for the last email.

Valorie

On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman <
valorie.zimmer...@gmail.com> wrote:

>
> Hello GSoC mentors, and teams supporting mentors,
>
> TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas; read
> https://community.kde.org/GSoC. Now.
>
> Every year, we've asked for more time to get ramped up for GSoC, and so
> now is the time for organizations to apply[1]. We have begun to write our
> application, and  that means that our Ideas page needs to be filled NOW,
> because that is the prime consideration for the GSoC team once the Org
> Applications deadline has passed.
>
> The quality of our ideas and the guidance they give our students are the
> most important part of our application. Please begin filling in your ideas
> now if you have not already, and ensure that that page is comprehensive,
> accurate and attractive. Including screenshots and other images is allowed,
> if it enriches the idea for a project. *Please ensure complete information
> about how to contact the team*; this is crucial.
>
> Also, take a look at the landing page https://community.kde.org/GSoC.
> Experienced mentors agree that:
>
> 1. commits must be made before the student proposal is submitted, and
> linked on that proposal, and
>
> 2. that regular communication from the student must be initiated by the
> student at least weekly, and we expect daily or nearly daily communication
> with the team in a more informal way.
>
> Be sure to point students to that information, as this should lower the
> number of proposals, while raising the quality.
>
> 1. https://developers.google.com/open-source/gsoc/timeline
>
> PS: If your team has an Idea, ensure that you have mentors for it, and
> that those mentors are subscribe to KDE-Soc-Mentor list. Remove any ideas
> without mentors available, please. Now, before you forget!
>
> Valorie
>


-- 
http://about.me/valoriez

Review of 'plasma-active-window-control' project

[Martin Kostolný]

Hi!

I'm starting a new review thread for project:

https://phabricator.kde.org/source/plasma-active-window-control/

Best Regards,
Martin

Review of 'plasma-redshift-control' project

[Martin Kostolný]

Hi!

I'm starting a review thread for project:

https://phabricator.kde.org/source/plasma-redshift-control/

..based on responses from Albert, Ingo and Ben from thread "2 New Plasmoids in 
Kdereview" here on kde-core-devel. Thanks for the fast responses!

Best Regards,
Martin