Re: Moving Baloo forward
On Fri, Jan 17, 2014 at 1:47 AM, Albert Astals Cid aa...@kde.org wrote: Thus my suggestion is that after we get the wiki done and we explain clearly the situation as Thomas Lübking suggested (i.e. if you really really really really need what Nepomuk provides and can't accept a single regression in that field, do not upgrade), we go ahead with moving to Baloo instead of Nepomuk. What do you think? Sounds like a plan to me. +1 Cheers -- Martin Klapetek | KDE Developer
Re: Moving Baloo forward
On Friday, 2014-01-17, 01:47:17, Albert Astals Cid wrote: If we move now, in one year we will have had 1 year of real usage uncovering bugs and 1 year of bugfixes. If we move in one year, we will have lost that 1 year of real usage (since few people will be using it) and so in one year we will be in the same situation as we are now. Isn't there also the option to switch selected applications to Baloo now and others later, e.g. on their respective maintainers schedule? For example move KDE PIM to Baloo, which I think we have agreement on internally, and migrating our data in the process. That should not create any issues since it is unlikely that anyone was accessing our data directly through Nepomuk instead of using our APIs. That should give Baloo and its APIs a lot of testing, almost certainly improve the situtation for us (KDE PIM), but neither touch anyone else's semantic data nor interrrupt their technology stack (as a bonus move load away from their stack). There might be other examples of apps that can safely move without affecting any other current user of Nepomuk. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo and Baloo-widgets into KDE SC
Am Freitag, 10. Januar 2014, 11.28:34 schrieb Sebastian Kügler: Hey, Morning sebas and Co Here finally my answer to this thread. [snip] - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? Maybe this feature is worth delaying then? Is anybody of the Digikam team reading this? Or should somebody contact them? Please speak. - Dolphin - Gwenview - Conquiere - KPhotoalbum - Kamoso (seems so be ready in time) - Kdenlive (out of the most popular KDE apps, with some man power problems atm, ok, but nonetheless) - Nepomuk-webminer and Nepomuktvnamer Let me point out the obvious here: We can discuss possible quality problems for a few more weeks, *OR* we use the time to actually test the code on a wider range of systems. This way we wouldn't have to guess so much about possible impact to other apps, and we can judge much better how ready Baloo is. Sometimes pointing out the obvious is not bad ;-). Of course you're right. I just had the subjective impression that it's holding back. Which changed (at least my perception of it) which is great. Don't see Baloo as a third party service that someone else has to fix and debug, rather get on the train, test it, report your experience and make it possible to get it solidly working. Ok. [snip: Plasma Active] So in conclusion I think that a change of Nepomuk to Baloo in 4.x without a 100% (very very well tested!) migration plan and testing is a no-go (from my side, just me). I've the strong feeling that such big changes are for something like kf5 and a port of the apps to kf5. I'm not strictly against this. Actually, we have some lenience with the long term support workspace out, so we can recommend people to use that, if they're slightly more adventurous, run 4.13, if they are completely mad, help us getting Plasma 2 in shape. That's quite a nice array of options. Communicated in the right way to our downstreams, this helps us to avoid problems. This I don't get as it speaks against all I told people about all our three different releases (apps, workspaces and platform). But I think this may be a misunderstanding. So my conclusion. Let's do it asap and know and see the effects and get as many testers as possible so that we can release 4.13 with a great Nepomuk replacement or better evolution of Nepomuk. Thx Mario PS: About Jan's question if there are more applications that share KPhotoAlbum's slight use of Nepomuk. TBH I don't know.
Re: Review Request 114623: kjs: Implement es6 Math.fround
On Dec. 24, 2013, 1:13 p.m., Martin Tobias Holmedahl Sandsmark wrote: what a silly function, but looks okay to me. Shouldn't this go to KF5? Also kdelibs is feature frozen... - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114623/#review46132 --- On Jan. 16, 2014, 5:56 p.m., Bernd Buschinski wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114623/ --- (Updated Jan. 16, 2014, 5:56 p.m.) Review request for kdelibs. Repository: kdelibs Description --- kjs: Implement es6 Math.fround Diffs - kjs/math_object.h 3d193dd kjs/math_object.cpp 89835e5 Diff: https://git.reviewboard.kde.org/r/114623/diff/ Testing --- Basic Mozilla tests: Math.fround(0) // 0 Math.fround(1) // 1 Math.fround(1.337) // 1.337123977661 Math.fround(1.5) // 1.5 Math.fround(NaN) // NaN Math.fround(Infinity) // Inf Math.fround(-Infinity) // -Inf Thanks, Bernd Buschinski
Re: Review Request 114623: kjs: Implement es6 Math.fround
On Dec. 24, 2013, 1:13 p.m., Martin Tobias Holmedahl Sandsmark wrote: what a silly function, but looks okay to me. Aleix Pol Gonzalez wrote: Shouldn't this go to KF5? Also kdelibs is feature frozen... yes, it should go into kf5 as well, but it was decided some time ago that missing implementations in kjs and khtml counted as bugs. - Martin Tobias Holmedahl --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114623/#review46132 --- On Jan. 16, 2014, 5:56 p.m., Bernd Buschinski wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114623/ --- (Updated Jan. 16, 2014, 5:56 p.m.) Review request for kdelibs. Repository: kdelibs Description --- kjs: Implement es6 Math.fround Diffs - kjs/math_object.h 3d193dd kjs/math_object.cpp 89835e5 Diff: https://git.reviewboard.kde.org/r/114623/diff/ Testing --- Basic Mozilla tests: Math.fround(0) // 0 Math.fround(1) // 1 Math.fround(1.337) // 1.337123977661 Math.fround(1.5) // 1.5 Math.fround(NaN) // NaN Math.fround(Infinity) // Inf Math.fround(-Infinity) // -Inf Thanks, Bernd Buschinski
Review Request 115079: don't install dbus interface files in kglobalaccel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115079/ --- Review request for kde-workspace and Martin Gräßlin. Repository: kde-workspace Description --- to go with https://git.reviewboard.kde.org/r/115078/ use local dbus interface files Diffs - Diff: https://git.reviewboard.kde.org/r/115079/diff/ Testing --- Thanks, Jonathan Riddell
Re: Moving Baloo forward
Hey Albert Thanks for sending this email. On Friday 17 January 2014 01:47:17 Albert Astals Cid wrote: Hi guys, seems we have reached a kind of impasse regarding what to do with Baloo and Nepomuk. Since the 4.13 freeze is coming sooner than you think (less than 6 weeks) I'd like to try to get it moving again. Here comes my proposal: Create a wiki where you clearly explain: * What is Baloo * Why Nepomuk is unfixable * What's the strategy of migrating Nepomuk data to Baloo * Can Nepomuk and Baloo run together? If so does data flow both ways? No way? One way? * For each application that we know uses nepomuk - Is it going to be ported? When? - If not ported can it still run the same with nepomuk installed? - If not ported what's the harm if nepomuk is not installed? * What is the support plan for Baloo based in kdelibs4 once KF5 is released? I guess that most of the answers can be extracted from the emails of the discussion, but having a central place that people can go and read surely helps. http://community.kde.org/Baloo Could someone please prooof read this page and let me know where it can be improved? Now my personal opinion is that unless some of the answers are catastrophic (i.e. something like It will eat all your data) we should move to Baloo as soon as possible. For me the situation is this: * I accept the domain experts opinion that Nepomuk is unfixable * That means we need a replacement, Baloo * Baloo is [almost] ready * Baloo will have bugs (as all software does) Now with this situation we can do two things: * Move to Baloo as soon as possible * Move to Baloo sometime in the future (let's say 1 year) If we move now, in one year we will have had 1 year of real usage uncovering bugs and 1 year of bugfixes. If we move in one year, we will have lost that 1 year of real usage (since few people will be using it) and so in one year we will be in the same situation as we are now. On top of that we have the possibility that the Baloo guys have lost motivation Thus my suggestion is that after we get the wiki done and we explain clearly the situation as Thomas Lübking suggested (i.e. if you really really really really need what Nepomuk provides and can't accept a single regression in that field, do not upgrade), we go ahead with moving to Baloo instead of Nepomuk. What do you think? A huge +1. I've sent an email to the kde-promo team asking them to help me with the article. Given that we're clearly informing the world - Do not upgrade if you want to continue using Nepomuk, it does not make sense to still ship the Nepomuk KCM and kioslave. I will be removing them from kde-runtime.
Re: Moving Baloo and Baloo-widgets into KDE SC
On Friday 17 January 2014 11:54:06 Mario Fux KDE ML wrote: Am Freitag, 10. Januar 2014, 11.28:34 schrieb Sebastian Kügler: Hey, Morning sebas and Co Here finally my answer to this thread. [snip] - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? Maybe this feature is worth delaying then? Is anybody of the Digikam team reading this? Or should somebody contact them? Please speak. I've emailed them today.
Moving KFIleMetadata into KDE SC
Hey guys I should have posted this with the Baloo thread, but since I did not - WIth KDE SC 4.10, Nepomuk dropped support for Strigi and implemented their own indexing library. This code was part of nepomuk-core. With Baloo, this code has been migrated into its own repository called kfilemetadata. I'm hoping to make it into its own framework some point in the future. I would like to move this code into KDE SC along with Baloo. None of the code is new. It has all been taken from neopmuk-core. The only change is that the indexers no longer use the ontologies. -- Vishesh Handa
Re: Review Request 115079: don't install dbus interface files in kglobalaccel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115079/#review47586 --- there's no diff - should there be? - Thomas Lübking On Jan. 17, 2014, 4:09 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115079/ --- (Updated Jan. 17, 2014, 4:09 p.m.) Review request for kde-workspace and Martin Gräßlin. Repository: kde-workspace Description --- to go with https://git.reviewboard.kde.org/r/115078/ use local dbus interface files Diffs - Diff: https://git.reviewboard.kde.org/r/115079/diff/ Testing --- Thanks, Jonathan Riddell
Re: Moving Baloo forward
On Friday 17 January 2014 17:50:38 Vishesh Handa wrote: Hey Albert Thanks for sending this email. On Friday 17 January 2014 01:47:17 Albert Astals Cid wrote: Hi guys, seems we have reached a kind of impasse regarding what to do with Baloo and Nepomuk. Since the 4.13 freeze is coming sooner than you think (less than 6 weeks) I'd like to try to get it moving again. Here comes my proposal: Create a wiki where you clearly explain: * What is Baloo * Why Nepomuk is unfixable * What's the strategy of migrating Nepomuk data to Baloo * Can Nepomuk and Baloo run together? If so does data flow both ways? No way? One way? * For each application that we know uses nepomuk - Is it going to be ported? When? - If not ported can it still run the same with nepomuk installed? - If not ported what's the harm if nepomuk is not installed? * What is the support plan for Baloo based in kdelibs4 once KF5 is released? I guess that most of the answers can be extracted from the emails of the discussion, but having a central place that people can go and read surely helps. http://community.kde.org/Baloo Could someone please prooof read this page and let me know where it can be improved? Reading it from a outside-world-communication perspective :d Now my personal opinion is that unless some of the answers are catastrophic (i.e. something like It will eat all your data) we should move to Baloo as soon as possible. For me the situation is this: * I accept the domain experts opinion that Nepomuk is unfixable * That means we need a replacement, Baloo * Baloo is [almost] ready * Baloo will have bugs (as all software does) Now with this situation we can do two things: * Move to Baloo as soon as possible * Move to Baloo sometime in the future (let's say 1 year) If we move now, in one year we will have had 1 year of real usage uncovering bugs and 1 year of bugfixes. If we move in one year, we will have lost that 1 year of real usage (since few people will be using it) and so in one year we will be in the same situation as we are now. On top of that we have the possibility that the Baloo guys have lost motivation Thus my suggestion is that after we get the wiki done and we explain clearly the situation as Thomas Lübking suggested (i.e. if you really really really really need what Nepomuk provides and can't accept a single regression in that field, do not upgrade), we go ahead with moving to Baloo instead of Nepomuk. What do you think? A huge +1. I've sent an email to the kde-promo team asking them to help me with the article. Will help where I can. Given that we're clearly informing the world - Do not upgrade if you want to continue using Nepomuk, it does not make sense to still ship the Nepomuk KCM and kioslave. I will be removing them from kde-runtime. signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
On Friday 17 January 2014 17:50:38 Vishesh Handa wrote: On Friday 17 January 2014 01:47:17 Albert Astals Cid wrote: I guess that most of the answers can be extracted from the emails of the discussion, but having a central place that people can go and read surely helps. http://community.kde.org/Baloo Could someone please prooof read this page and let me know where it can be improved? It would be useful, if the #Porting_your_Application section would contain some link to the actual porting instructions/example code, or at least some API documentation link. Remaining applications can get ported faster this way. Christoph Feck (kdepepo) KDE Quality Team
