Re: Python bindings using cppyy (was: An update on Python bindings)

[Albert Astals Cid]

El dissabte, 13 de gener de 2018, a les 18:05:45 CET, Shaheed Haque va 
escriure:
> Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and
> also Qt5 (see below) showing signs of life. 
> Notes:

This is awesome, i'm really happy we're in a point that framework-by-framework 
is possible and that it all seems to be upstream so it's a "hopefully bigger 
group of people" maintaining it :)

Keep it up!

Cheers,
  Albert

> 
> 
>1. The packaging has advanced to the point where I think ECM-based
>framework-by-framework bindings are a real possibility, with both Py2 and
> Py3. AFAICS, this addresses the main feedback received to date. 2. With
> reference to the remark about tracking dependencies between frameworks,
> apologies for the delayed response as I somehow missed the email. I note
> that the dependencies currently in CMake often seem incomplete. I'll bring
> that to the community separately.
>3. There is one issue still open upstream (
>   
> https://bitbucket.org/wlav/cppyy/issues/16/pragma-link-defined_in-seems-to-> 
> select). However, I don't consider this to be a showstopper...we might even
> be able to live with it as is.
>4. For me, the jury is still out on PyQt versus a new set of cppyy-based
>Qt bindings. Clearly PyQt is solid and mature, but the limitations really
> concern me (if anybody wants to know more, I'm happy to discuss, but let's
> do that in another thread please). Now, given that there are examples in
> the wild of interoperating cppyy/cling/ROOT with PyQt, I'm going to
> sidestep this question but am playing with a cppyy-based approach. At this
> point, all of Qt has basic cppyy-based bindings, and the next step is to
> tackle things like finding a way to express the object
>ownership/destruction rules in a more-or-less systematic way.
>5. On the P2/P3 question, I'm presently still committed to both P2 and
>P3. I *have* had a couple of minor occasions where P3-only might have
> been nice *for my code*, but if I do find an issue that tips the balance,
> or I find some serious benefit *for the bindings*, I'll drop P2. One
> possible such benefit would be if I can see a sane way to address PEP484
> type hints.
> 
> To get here, I had to build a subset of the tooling I previously had
> developed for the SIP-based approach. The big difference is the absence of
> any need to support customisation of the generated bindings. I am hopeful
> that in the worst case, there might be some minimal customisation (known as
> Pythonisations in cppyy parlance) such as for #4 above, but nothing like
> the scale needed for SIP.
> 
> The core tooling is not specific to KF5 or KDE or Qt5, and is developed in
> upstream cppyy over on bitbucket.org. The core tooling is built around
> CMake, notably for the generation phase and the C++ library build.
> 
> The PoC extends the core tooling with Pythonic packaging and installation
> using pip/wheels, also from CMake. As before I would look for help to get
> an ECM equivalent, possibly based on the same approach but perhaps
> including CI and distribution via PyPi.
> 
> Finally, now would be a good time for anybody else who wants to get
> involved to step up, especially as a new job limits my free time.
> 
> Thanks, Shaheed
> 
> P.S. Not to stoke the the P2/P3 wars unnecessarily, but while I know that
> upstream Clang just added P3 support in the clang 5.0 release, current
> Ubuntu only packages it for 2.7.14. So I won't be moving yet...
> 
> On 5 November 2017 at 13:23, Boudewijn Rempt  wrote:
> > On Sat, 4 Nov 2017, Chris Burel wrote:
> > > I think this is a remarkably short sighted statement. It assumes that
> > 
> > people that would use these bindings have no existing Python codebase at
> > all, and can afford to start a brand new project. The reality is much
> > different.
> > 
> > > Let's take a specific example. I have 6 years experience writing Python
> > 
> > for the visual effects industry. We have a 10 year old Python 2 codebase.
> > We also use an application from Autodesk called Maya. It has been a Qt 4
> > application with Python 2 embedded since 2012. In 2016 they jumped to qt 5
> > and pyside2. Now Autodesk knows that companies have built large codebase
> > around their product that requires Python 2. What would've happened if
> > pyside2 did not support Python 2.7? They'd be stuck either forcing all
> > their customers to move to Python 3 and risk people not wanting the new
> > version of the software, or they'd be prevented from moving to Qt 5.
> > 
> > 
> > You will have to switch to Python 3 by 2019, since that's what the VFX
> > Reference Platform says. If you haven't started on the migration yet,
> > you're very late. And the VFX Refernece Platform is basically Autodesk
> > telling the rest of the industry what to use, including their weird
> > patchset for Qt...
> > 
> > > So no, Python 2 is not dead. Not by a long shot.
> > 
> > For VFX, it will be dead in 2019. See 

Re: Rebase of kopete branch and push it to master

[Albert Astals Cid]

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. 

Just merge master-kf5 into master.

master as it is right now works, no? (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. Or 
you're saying that you want to rebase your work branches?

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

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

[Albert Astals Cid]

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

Rebase of kopete branch and push it to master

[Pali Rohár]

Hi!

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

For future (to prevent any such problem with rebasing), staging areas
would be outside of main KDE git repository.

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. (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'm not subscribed to kde-core-devel, so please CC me on reply.

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


signature.asc
Description: PGP signature

Re: KDE inclusion

[Luigi Toscano]

Michael Reeves ha scritto:
> Sorry meant this to go to everyone.
> 
> I did this based off what Ubuntu was using at the time.  The repo is here
> https://bitbucket.org/reporter123/kdiff3
> . Master is currently set the
> require CMake 3.1 but as of this moment that is just a number change. My
> concern here was C++11 feature dectect which is not implemented in earlier
> versions. Right now that is not critical. I was not aware of the parallel
> effort at https://cgit.kde.org/scratch/thomasfischer/kdiff3.git/log/?h=kf5
> . Command
> line parsing is fully operational on mine. To my knowledge it is fully
> operational and I have been using it on my machine. I generally work with two
> way comparisons.

Adding explicitly Thomas (I don't remember if he reads this list).

Thomas, some context below or better on:
https://marc.info/?t=15156672876=1=2

> 
> On Thu, Jan 11, 2018 at 6:24 PM, Albert Astals Cid  > wrote:
> 
> El dijous, 11 de gener de 2018, a les 12:15:15 CET, Kevin Funk va 
> escriure:
> > On Tuesday, 9 January 2018 21:06:36 CET Michael Reeves wrote:
> > > 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?
> >
> > Heya,
> >
> > Note: kdiff3 right now is hosted & developed on SourceForge.
> >
> > I'd love to see kdiff3 being adopted by KDE again (it former was KDE
> > extragear if I understood correctly). kdiff3 is a super useful tool -- 
> and
> > right now development has stalled a bit.
> >
> > Talked to Joachim (the original author) a few weeks ago, where he 
> stated he
> > just doesn't have the time maintaining it anymore, really. I've CC'd 
> Joachim
> > so he can tell us whether he's okay with having kdiff3 developed further
> > under the KDE umbrella.
> 
> I guess this is the most important question, if we can keep using the 
> kdiff3
> name under's Joachim's blessing or we have to "fork it" and find a new 
> name.
> 
> Cheers,
>   Albert
> 
> >
> > I don't really know the process of having it integrated either. I'll 
> leave
> > that to others.
> >
> > Kudos for doing the KF5 port!
> >
> > Regards,
> > Kevin
> 

-- 
Luigi

Re: New KDE application

[Sayan Biswas]

Adding other lists.

On 10-Jan-2018 11:49 PM, "Sayan Biswas"  wrote:

> Hi,
>
> A very happy new year to all. Hope you guys are doing good. :)
>
> Me and Rahul (CC'ed; IRC nick - rahulch) came up with an idea for a
> new application in KDE, and we were hoping to get an opinion on it.
>
> The central idea behind the app will be to manage the expenses of a
> group of users. As a user, you can create one or more groups, add
> members to them, and add entries for expenses for a given group. You
> can also check the outstanding balances and choose to settle-up with one
> or more members. There will be options for fine-tuning a given entry -
> decide who all have born the total expenditure and by what
> proportions, how should the total expense be divided among the members
> (equally/specific amounts/etc), add pictures for receipts, add
> comments, and so on and so forth.
>
> We are planning to start off with desktop application with a decentralised
> approach, i.e. the users will hold the data of the shared expenses. Now
> again,
> there is a possibility of tampering with the expenditure so we might need
> to
> set a centralised archived or something similar data set to maintain the
> integrity and persistence of a transaction. We are open to opinions and
> discussions for this also. Further to that we will be building mobile
> application for the users ease of usage and add expenditure on the go.
> After
> all, mobiles are more widely used by user than desktop application.
>
>
> For settling up we were thinking of integrating some standard payment
> gateways (PayPal, etc) but I am not sure of how much of this
> integration is possible in KDE. Until then we can just maintain a
> transaction record indicating that members A and B have settled up. We
> were also considering developing a cryptocurrency (we could call it
> KCoin or something) that would serve as a means of payment. Opinions
> are welcome in this particular segment as possibilities can be immense.
>
> As for maintaining the ledgers, we wanted to implement it using
> blockchain, but again, I am not sure if it can be done in KDE, or if
> we have some libraries that support blockchain implementation, etc.
>
> An application like this comes in handy when a group of people need to
> manage their regular expenses, and we thought it might be a good idea
> to have something similar in KDE. The target audience for this will be
> college groups, work groups, school groups, etc whoever is entitled to
> shared expenditure. We would love to get your feedback, mainly on the
> feasibility of the features mentioned above.
>
>
> Regards,
> Sayan
>

Re: 2 New Plasmoids in Kdereview

[Martin Kostolný]

(it seems my last mail didn't get to kde-core-devel, so here it it with an 
update)

Hi Ben, Ingo,

that is right, my previous mail (from the night 2018-01-11) 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.

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 :).

Sorry for any inconvenience I may have caused.

Thank You,
Martin


On sobota 13. ledna 2018 10:08:01 CET Ben Cooksley wrote:
> On Fri, Jan 12, 2018 at 11:18 AM, 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?
> 
> Oops, if such a thread hasn't been started then we do indeed need to
> get a review thread underway.
> 
> >
> >
> > Regards,
> > Ingo
> 
> Cheers,
> Ben

Re: Re: KDE inclusion

[Michael Reeves]

Looks the original is a somewhat modified version of be348bcf1. It doesn't
have some of the windows specific code. Also kreplacements was not always
patched when updating code. I'm working on getting it updated with changes
Joachim has made.

On Fri, Jan 12, 2018 at 12:21 AM, Joachim Eibl  wrote:

> Hi,
>
> It's great to hear there is some ongoing effort to port KDiff3 to KF5.
> Thanks for informing me.
> 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.
>
> @Michael: It seems the repo at https://bitbucket.org/reporter123/kdiff3
> has no public access.
>
> Kudos,
> Joachim
>
>
> *Gesendet:* Donnerstag, 11. Januar 2018 um 22:28 Uhr
> *Von:* "Michael Reeves" 
> *An:* "Albert Astals Cid" 
> *Cc:* kde-core-devel@kde.org, "Joachim Eibl" 
> *Betreff:* Re: KDE inclusion
> Sorry meant this to go to everyone.
>
> I did this based off what Ubuntu was using at the time.  The repo is here
> https://bitbucket.org/reporter123/kdiff3. Master is currently set the
> require CMake 3.1 but as of this moment that is just a number change. My
> concern here was C++11 feature dectect which is not implemented in earlier
> versions. Right now that is not critical. I was not aware of the parallel
> effort at https://cgit.kde.org/scratch/thomasfischer/kdiff3.git/log/?h=kf5.
> Command line parsing is fully operational on mine. To my knowledge it is
> fully operational and I have been using it on my machine. I generally work
> with two way comparisons.
>
> On Thu, Jan 11, 2018 at 6:24 PM, Albert Astals Cid  wrote:
>>
>> El dijous, 11 de gener de 2018, a les 12:15:15 CET, Kevin Funk va
>> escriure:
>> > On Tuesday, 9 January 2018 21:06:36 CET Michael Reeves wrote:
>> > > 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?
>> >
>> > Heya,
>> >
>> > Note: kdiff3 right now is hosted & developed on SourceForge.
>> >
>> > I'd love to see kdiff3 being adopted by KDE again (it former was KDE
>> > extragear if I understood correctly). kdiff3 is a super useful tool --
>> and
>> > right now development has stalled a bit.
>> >
>> > Talked to Joachim (the original author) a few weeks ago, where he
>> stated he
>> > just doesn't have the time maintaining it anymore, really. I've CC'd
>> Joachim
>> > so he can tell us whether he's okay with having kdiff3 developed further
>> > under the KDE umbrella.
>>
>> I guess this is the most important question, if we can keep using the
>> kdiff3
>> name under's Joachim's blessing or we have to "fork it" and find a new
>> name.
>>
>> Cheers,
>>   Albert
>>
>> >
>> > I don't really know the process of having it integrated either. I'll
>> leave
>> > that to others.
>> >
>> > Kudos for doing the KF5 port!
>> >
>> > Regards,
>> > Kevin
>>
>>
>>
>

Aw: Re: KDE inclusion

[Joachim Eibl]

Hi,

 

It's great to hear there is some ongoing effort to port KDiff3 to KF5.

Thanks for informing me.

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.

 

@Michael: It seems the repo at https://bitbucket.org/reporter123/kdiff3

has no public access.

 

Kudos,

Joachim

 

 

Gesendet: Donnerstag, 11. Januar 2018 um 22:28 Uhr
Von: "Michael Reeves" 
An: "Albert Astals Cid" 
Cc: kde-core-devel@kde.org, "Joachim Eibl" 
Betreff: Re: KDE inclusion


Sorry meant this to go to everyone.

I did this based off what Ubuntu was using at the time.  The repo is here https://bitbucket.org/reporter123/kdiff3. Master is currently set the require CMake 3.1 but as of this moment that is just a number change. My concern here was C++11 feature dectect which is not implemented in earlier versions. Right now that is not critical. I was not aware of the parallel effort at https://cgit.kde.org/scratch/thomasfischer/kdiff3.git/log/?h=kf5. Command line parsing is fully operational on mine. To my knowledge it is fully operational and I have been using it on my machine. I generally work with two way comparisons.


 
On Thu, Jan 11, 2018 at 6:24 PM, Albert Astals Cid  wrote:

El dijous, 11 de gener de 2018, a les 12:15:15 CET, Kevin Funk va escriure:
> On Tuesday, 9 January 2018 21:06:36 CET Michael Reeves wrote:
> > 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?
>
> Heya,
>
> Note: kdiff3 right now is hosted & developed on SourceForge.
>
> I'd love to see kdiff3 being adopted by KDE again (it former was KDE
> extragear if I understood correctly). kdiff3 is a super useful tool -- and
> right now development has stalled a bit.
>
> Talked to Joachim (the original author) a few weeks ago, where he stated he
> just doesn't have the time maintaining it anymore, really. I've CC'd Joachim
> so he can tell us whether he's okay with having kdiff3 developed further
> under the KDE umbrella.

I guess this is the most important question, if we can keep using the kdiff3
name under's Joachim's blessing or we have to "fork it" and find a new name.

Cheers,
  Albert


>
> I don't really know the process of having it integrated either. I'll leave
> that to others.
>
> Kudos for doing the KF5 port!
>
> Regards,
> Kevin

 

Re: 2 New Plasmoids in Kdereview

[Martin Kostolný]

Hi Ben, Ingo,

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.

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 :).

Thank You,
Martin


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: KDE inclusion

[Michael Reeves]

Sorry meant this to go to everyone.

I did this based off what Ubuntu was using at the time.  The repo is here
https://bitbucket.org/reporter123/kdiff3. Master is currently set the
require CMake 3.1 but as of this moment that is just a number change. My
concern here was C++11 feature dectect which is not implemented in earlier
versions. Right now that is not critical. I was not aware of the parallel
effort at https://cgit.kde.org/scratch/thomasfischer/kdiff3.git/log/?h=kf5.
Command line parsing is fully operational on mine. To my knowledge it is
fully operational and I have been using it on my machine. I generally work
with two way comparisons.

On Thu, Jan 11, 2018 at 6:24 PM, Albert Astals Cid  wrote:

> El dijous, 11 de gener de 2018, a les 12:15:15 CET, Kevin Funk va escriure:
> > On Tuesday, 9 January 2018 21:06:36 CET Michael Reeves wrote:
> > > 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?
> >
> > Heya,
> >
> > Note: kdiff3 right now is hosted & developed on SourceForge.
> >
> > I'd love to see kdiff3 being adopted by KDE again (it former was KDE
> > extragear if I understood correctly). kdiff3 is a super useful tool --
> and
> > right now development has stalled a bit.
> >
> > Talked to Joachim (the original author) a few weeks ago, where he stated
> he
> > just doesn't have the time maintaining it anymore, really. I've CC'd
> Joachim
> > so he can tell us whether he's okay with having kdiff3 developed further
> > under the KDE umbrella.
>
> I guess this is the most important question, if we can keep using the
> kdiff3
> name under's Joachim's blessing or we have to "fork it" and find a new
> name.
>
> Cheers,
>   Albert
>
> >
> > I don't really know the process of having it integrated either. I'll
> leave
> > that to others.
> >
> > Kudos for doing the KF5 port!
> >
> > Regards,
> > Kevin
>
>
>