libkgeomap
Hi list! recently, I requested to move libkface from extragear/libs to to kdegraphics/libs, because KPhotoAlbum began to use it as the first non-Digikam program. This has been done in the meantime and now, we have a Digikam- independent libkface release to be found in unstable/applications (which can be used by distributors to create Digikam-independent libkface packages). Thanks again for the move :-) Recently, we started to use another library from Digikam in KPhotoAlbum, libkgeomap. Would it be possible (of course after some review etc.) to do the same with this library, for the same reasons? Probably, kdegraphics/libs would not be the right place for libkgeomap, as it depends on Marble, but kde-edu. Gilles Caulier from Digikam recently suggested that I asked for that, because apparently a lot of patching has been done to libkgeomap so that a stand-alone library release would be possible. I'm sure that the libkgeomap maintainers (esp. Gilles Caulier) will gladly change what has to be changed to get an independent release, and we would get the same benefits of it as the libkface move made. What do you think? Cheers, Tobias
Fwd: Re: [Kde-pim] Problems with infrastructure
Sending this to k-c-d, probably has been sent to me only by mistake: it offers additional insights on software. - Messaggio inoltrato - Oggetto: Re: [Kde-pim] Problems with infrastructure Data: sabato 13 dicembre 2014, 08:21:15 Da: Helio Chissini de Castro he...@kde.org A: Luca Beltrame lbeltr...@kde.org On Fri, Dec 12, 2014 at 8:25 PM, Luca Beltrame lbeltr...@kde.org wrote: Albert Astals Cid wrote: So what do you suggest, because we already tried gitlab and didn't work, is there any more github clones out there that may work for us? I don't There are at least a couple: - Gitbucket (written in Scala, mimics the GitHub interface) - Gogs (written in Go, see my previous mail on the topic) I've used both, but not at the scale KDE needs, though. ;) Gitbucket: - Uses its own embedded SSH (!) on a non standard port (like Gerrit) - There are a few issues with documentation - Java / Scala (not everyone's cup of tea) - Supports LDAP like KDE needs - No information on performance - No information on large number of repositories - Probably no customization of appearance Gogs: - Fast and lean - Go (not everyone's cup of tea) - Uses the system's SSH - Does not support yet LDAP like KDE wants (I filed issues about it upstream) - Inconsistent UI (not yet finished) - No information on customization of appearance - Strange way of configuration (copy ini file elsewhere, modify) - Behind Gitbucket in terms of features - No information on performance - No information on large number of repositories Gitbucket: https://github.com/takezoe/gitbucket Gogs: https://gogs.io Hope this helps. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 Let me enter on this discussion :-) In my previous company we used mercurial and for same reason they started to look some open source frameworks like github, discarding any paid solution. We had three ones on plate: - Phabricator http://phabricator.org/ https://github.com/phacility/phabricator - Apache Allura https://allura.apache.org/ - Rhodecode http://rhodecode.com This is the one we choosed, and is indeed very powerfull, the only part is that company behind it closed the source, but a fully open source fork is been done https://kallithea-scm.org/ So i'm throwing this three for us and maybe if one of then fit, we can use the same strategy we did years ago when we needed deal with svn, then git, then anything we used, help providing some code. Hope this helped in some way. Helio -- -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 signature.asc Description: This is a digitally signed message part.
Re: [Kde-pim] Problems with infrastructure
Kevin Kofler wrote: Hello Kevin, wants to use Gerrit. (It's not even a KF5 or kdelibs application, but a Qt-only one.) Then he can use whatever tools he wants. Problem solved. As Aleix said already, this does not help the discussion in any way. I can see, even if I'm far from being an expert here, that Jan has been quite constructive and the effort (adopted or not, it doesn't matter, as we're looking an the intentions here) was to make software better. Some may not agree with his choice of tools - but so far the discussion has been quite level-headed, and technical. I say that this is a good opportunity to evaluate what we have and what we need (Although need changes from project to project) without any aggressive (and frankly, hostile IMO) behavior. What justifies such an aggressive tone? Don't forget that even if you're a KDE contributor, you should always have the CoC in mind. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Re: [Kde-pim] Problems with infrastructure
In data sabato 13 dicembre 2014 08:21:15, hai scritto: We had three ones on plate: - Phabricator http://phabricator.org/ https://github.com/phacility/phabricator I think I've taken a look at that, but it was way too complex than what I could handle: I have no idea if it fits KDE's needs. that company behind it closed the source, but a fully open source fork is been done https://kallithea-scm.org/ This looks good, however the major roadblock is that it doesn't support SSH based cloning, meaning it would need some other glue to handle this. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 signature.asc Description: This is a digitally signed message part.
Re: Re: Ksshaskpass ?
On Sunday 14 December 2014 15:33:27 Thomas Lübking wrote: On Sonntag, 14. Dezember 2014 13:52:51 CEST, Jeremy Whiting wrote: Martin, Thomas, Is the implementation of InputGuard at https://github.com/luebking/qarma/commit/b568dd14d6e1f661791c4d67245c614f1 dc1986f with https://github.com/luebking/qarma/commit/3199c0a9810ed8f792b415e890425be8f 2e8034a complete then? complete? - Yes. Thomas happy? - No :-( The class grabs the keyboard for the (managed) focused widget in active windows (as it should), BUT the only protection against malicious losses is to regrab the keyboard every 500ms (and make the lineedit white on red if that fails) Martin suggested to declare X11 setups which allow to break grabbing unsupported, but I'm not entirely happy with that. We'd need to figure whether a) there's a way for a client to check whether it still holds the grab b) or alternatively adding a second client (ie. process) to guard the first one otherwise (by trying to grab the keyboard and when that works while client #1 is supposed to have the keyboard, sth.'s fishy here) b) wouldn't work in a case of attack using the allow break grabbing feature 1. dialog grabs keyboard 2. attacking process breaks grab and establish grabs 3. control process tries to grab keyboard and will fail as the attacking process holds a grab. should we copy that into kwidgetsaddons I assume kwidgetsaddons should use the KDE palette definitions (bad color?) - if color indication is sufficient. But that's subject for a kwidgetsaddons review. Yeah, we should get Thomas Pfeiffer on a review as he's an expert on useable security. Personally I also think that this needs some explanation on why it is insecure. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: [Kde-pim] Problems with infrastructure
On Mon, 15 Dec 2014, Luca Beltrame wrote: In data sabato 13 dicembre 2014 08:21:15, hai scritto: We had three ones on plate: - Phabricator http://phabricator.org/ https://github.com/phacility/phabricator I think I've taken a look at that, but it was way too complex than what I could handle: I have no idea if it fits KDE's needs. Just as a datapoint: phabricator is what blender is using now: http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator Boud
Re: [Kde-pim] Problems with infrastructure
On Monday, December 15, 2014 10.02:47 Boudewijn Rempt wrote: Just as a datapoint: phabricator is what blender is using now: http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator and many more (and larger): http://en.wikipedia.org/wiki/Phabricator#Users looks like a pretty cool system. the command line integration (arc) is quite nice and powerful. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part.
Re: New framework to review: KPackage
On Thursday 11 December 2014, Kevin Kofler wrote: Marco Martin wrote: In the past weeks I have been working on a new framework, called KPackage. You ARE aware that KPackage was the name of an old frontend for RPM and other package managers that used to be part of the KDE Software Compilation 4? open for suggestions for names.. -- Marco Martin
Re: [Kde-pim] Problems with infrastructure
On Dec 15, 2014 10:24 AM, Aaron J. Seigo ase...@kde.org wrote: On Monday, December 15, 2014 10.02:47 Boudewijn Rempt wrote: Just as a datapoint: phabricator is what blender is using now: http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator and many more (and larger): http://en.wikipedia.org/wiki/Phabricator#Users looks like a pretty cool system. the command line integration (arc) is quite nice and powerful. Yeah. Wikimedia just switched to it for bug tracking. More will follow. Made my life as product manager there a lot easier already. Cheers Lydia -- Aaron J. Seigo
Re: [Kde-pim] Problems with infrastructure
On Saturday 13 December 2014 18:13:41 Albert Astals Cid wrote: El Dissabte, 13 de desembre de 2014, a les 13:46:24, Jan Kundrát va escriure: On Friday, 12 December 2014 22:44:39 CEST, Albert Astals Cid wrote: That's very different from saying whole KDE should just switch to Gerrit, and I'm not proposing that. Some people have made themselves clear that no change is going to happen, and I can live with that. Where was that discussed? Which people is that? (Removing PIM from the list, because I don't see this as a PIM matter.) That was the impression which I got from the #kde-devel IRC channel and the kde-core-devel ML right after that frameworks BoF during Akademy. When re-reading the threads and the IRC logs today, I no longer have the impression that there was a clear, absolute and strict no, but there was nonetheless IMHO quite a strong resistance to using something as horrific as Gerrit. That might explain why I think that there will be a subset of people who won't be fine with any change, and because I respect their opinion, I don't want to force such a change upon them. As i said there is value in uniformity of the tooling, I like to think we're all reasonable people and understand that if the majority thinks it's a better tool, it makes sense to move to that tool. That's what happened with git. And if after evaluating it, it doesn't make sense, we don't. That's what happened with gitlab. Now to me it seems that you're basically saying you do what you want, i'll keep using my stuff. Which i find sad since it's creating artificial barriers between you and my :/ It also puts the discussion about a possible switch to gerrit in a weird situaion since we either all switch and have uniformity or we don't and then we end up with reviewborad+gerrit :/ Personally, I don't see why its a bad thing to have two options, if both fulfill a different users needs. Reviewboard is apparently liked by some, and its certainly simple to send trivial patches with it. Gerrit otoh is much better for people who work a lot on projects, as you can get much more productive with it. You just use git, and the rest is handled by the web ui. So, basically, from my point of view -- the tools are here, the CI is done.i That CI bits in particular make the workflow much more appealing to me. Now it's up to the KDE developers to come to a decision whether they want that or not. Maybe you could start a thread explaining why gerrit is better than reviewboard nd why should we switch to it? I can just say that I like using it in the setup they have for Qt. Much more productive to work on patch sets and then pushing them to an alias remote. Then I can fix them up and/or rebase and push again to update everything. With reviewboard, I'd need to manually push each individual patch, and updating them is again as much work. Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: [Kde-pim] Problems with infrastructure
On Monday, 15 December 2014 10:46:03 CEST, Lydia Pintscher wrote: Yeah. Wikimedia just switched to it for bug tracking. More will follow. My understanding of the reason behind this switch is that they are PHP programmers, so they prefer to work with software written in PHP, Made my life as product manager there a lot easier already. I do see a plan for migrate from Gerrit to Phabricator on your wiki now, but the same page also says We need help learning about the possibilities of Phabricator in this area: what is missing, what exists in a different way, what is remarkably interesting, which are the blockers that should be reported upstream?. Considering that this is different than what I heard a month ago, and given that there's AFAIK no code review in your deployed UI now, I wonder what the plan is. With kind regards, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Fwd: Re: [Kde-pim] Problems with infrastructure
On Monday, 15 December 2014 07:34:24 CEST, Luca Beltrame wrote: - Apache Allura https://allura.apache.org/ That is said to support pull requests, but I wasn't able to find an example of that in their website. Got one? Also, loading a list of commits took tens of second at the time I tried it :(. - Rhodecode http://rhodecode.com This is the one we choosed, and is indeed very powerfull, the only part is that company behind it closed the source, but a fully open source fork is been done https://kallithea-scm.org/ The documentation again says that it supports pull requests, and I was able to find two of them in total in their repos. I don't think that it's a particularly well-tested feature, then. One was from June, the other from October 2014. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: [Kde-pim] Problems with infrastructure
On Mon, Dec 15, 2014 at 2:58 AM, Kevin Kofler kevin.kof...@chello.at wrote: Albert Astals Cid wrote: It also puts the discussion about a possible switch to gerrit in a weird situaion since we either all switch and have uniformity or we don't and then we end up with reviewborad+gerrit :/ Or we just stop the Gerrit experiment in the core KDE projects as a failure (it was always made clear that it is only an experiment and can be ended at any moment), and kick out Trojitá from KDE if Jan absolutely wants to use Gerrit. (It's not even a KF5 or kdelibs application, but a Qt-only one.) Then he can use whatever tools he wants. Problem solved. Our very own manifesto, which we've established not so long ago, does not dictate that a project must be kf5 or kdelibs based application to be considered a KDE project. Also, this is a horrendous and concerning way of speaking, please don't do that again. Cheers -- Martin Klapetek | KDE Developer
Re: [Kde-pim] Problems with infrastructure
On Mon, Dec 15, 2014 at 11:01 AM, Jan Kundrát j...@kde.org wrote: On Monday, 15 December 2014 10:46:03 CEST, Lydia Pintscher wrote: Yeah. Wikimedia just switched to it for bug tracking. More will follow. My understanding of the reason behind this switch is that they are PHP programmers, so they prefer to work with software written in PHP, That's part of the reason. Another is very good upstream support for us. Made my life as product manager there a lot easier already. I do see a plan for migrate from Gerrit to Phabricator on your wiki now, but the same page also says We need help learning about the possibilities of Phabricator in this area: what is missing, what exists in a different way, what is remarkably interesting, which are the blockers that should be reported upstream?. Considering that this is different than what I heard a month ago, and given that there's AFAIK no code review in your deployed UI now, I wonder what the plan is. Experiments and investigations are underway now. I don't know what the timeline of the team working on that is but https://phabricator.wikimedia.org//project/board/9/ is their workboard. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors / KDE Community Working Group http://kde.org - http://open-advice.org
Re: [Kde-pim] Problems with infrastructure
Aaron J. Seigo wrote: looks like a pretty cool system. the command line integration (arc) is quite nice and powerful. I re-read the docs and I guess I got confused by the many modules it is made up of. I'll look into installing it on my own HW during the holidays, to see how it goes (after seeing both gitbucket and gogs, one more won't hurt ;) -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Re: Fwd: Re: [Kde-pim] Problems with infrastructure
Jan Kundrát wrote: - Apache Allura Also, loading a list of commits took tens of second at the time I tried it :(. IIRC, I think Allura was just proposed once or twice, without much follow up (but I'm the least knowledgeable person here. ;) [kallithea] able to find two of them in total in their repos. I don't think that it's a particularly well-tested feature, then. One was from June, the other from October 2014. If that's the case, that leaves phabricator yet to be tested. Both Gogs and Gitbucket (from my previous mail) should support PRs (I haven't been able to test them, as they run on public-yet-private instances). -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Re: libkgeomap
I would just to indicate that libkgeomap is already ported to KF5, as libkipi, libkexiv2, libkface, and libkdcraw. see this wiki page for details : https://techbase.kde.org/Projects/Digikam/CodingSprint2014#KF5.2FQt5_Port_Status Gilles Caulier 2014-12-14 18:57 GMT+01:00 Tobias Leupold tobias.leup...@web.de: Hi list! recently, I requested to move libkface from extragear/libs to to kdegraphics/libs, because KPhotoAlbum began to use it as the first non-Digikam program. This has been done in the meantime and now, we have a Digikam- independent libkface release to be found in unstable/applications (which can be used by distributors to create Digikam-independent libkface packages). Thanks again for the move :-) Recently, we started to use another library from Digikam in KPhotoAlbum, libkgeomap. Would it be possible (of course after some review etc.) to do the same with this library, for the same reasons? Probably, kdegraphics/libs would not be the right place for libkgeomap, as it depends on Marble, but kde-edu. Gilles Caulier from Digikam recently suggested that I asked for that, because apparently a lot of patching has been done to libkgeomap so that a stand-alone library release would be possible. I'm sure that the libkgeomap maintainers (esp. Gilles Caulier) will gladly change what has to be changed to get an independent release, and we would get the same benefits of it as the libkface move made. What do you think? Cheers, Tobias
[Kde-pim] Re: Problems with infrastructure
On Montag, 15. Dezember 2014 11:16:35 CEST, Martin Klapetek wrote: Also, this is a horrendous and concerning way of speaking, please don't do that again. Given what he wrote, how he wrote and *when* he wrote, he probably has a very hard day - after figuring that *yesterday* was Sunday ;-) Cheers, Thomas PS: If you believe that a drunken person can not type correctly - that does not comply with the Austrians I happen to know :) Large parts of the mail do not make sense at all, though.
Re: New framework to review: KPackage
On Monday, December 15, 2014 10:31:04 David Edmundson wrote: On Mon, Dec 15, 2014 at 10:25 AM, Marco Martin notm...@gmail.com wrote: On Thursday 11 December 2014, Kevin Kofler wrote: Marco Martin wrote: In the past weeks I have been working on a new framework, called KPackage. You ARE aware that KPackage was the name of an old frontend for RPM and other package managers that used to be part of the KDE Software Compilation 4? open for suggestions for names.. KPackage isn't a user facing name, I don't think we need to rename anything. Same thought here. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: New framework to review: KPackage
On Mon, Dec 15, 2014 at 12:50 PM, Sebastian Kügler se...@kde.org wrote: On Monday, December 15, 2014 10:31:04 David Edmundson wrote: On Mon, Dec 15, 2014 at 10:25 AM, Marco Martin notm...@gmail.com wrote: On Thursday 11 December 2014, Kevin Kofler wrote: Marco Martin wrote: In the past weeks I have been working on a new framework, called KPackage. You ARE aware that KPackage was the name of an old frontend for RPM and other package managers that used to be part of the KDE Software Compilation 4? open for suggestions for names.. KPackage isn't a user facing name, I don't think we need to rename anything. Same thought here. My thoughts were about someone trying to use kpackage-the-framework and looking for docs, other uses, and git repos. There are a lot of hits for kpackage-the-application creating a lot of noise. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: [Kde-pim] Problems with infrastructure
El Dilluns, 15 de desembre de 2014, a les 10:48:16, Milian Wolff va escriure: On Saturday 13 December 2014 18:13:41 Albert Astals Cid wrote: El Dissabte, 13 de desembre de 2014, a les 13:46:24, Jan Kundrát va escriure: On Friday, 12 December 2014 22:44:39 CEST, Albert Astals Cid wrote: That's very different from saying whole KDE should just switch to Gerrit, and I'm not proposing that. Some people have made themselves clear that no change is going to happen, and I can live with that. Where was that discussed? Which people is that? (Removing PIM from the list, because I don't see this as a PIM matter.) That was the impression which I got from the #kde-devel IRC channel and the kde-core-devel ML right after that frameworks BoF during Akademy. When re-reading the threads and the IRC logs today, I no longer have the impression that there was a clear, absolute and strict no, but there was nonetheless IMHO quite a strong resistance to using something as horrific as Gerrit. That might explain why I think that there will be a subset of people who won't be fine with any change, and because I respect their opinion, I don't want to force such a change upon them. As i said there is value in uniformity of the tooling, I like to think we're all reasonable people and understand that if the majority thinks it's a better tool, it makes sense to move to that tool. That's what happened with git. And if after evaluating it, it doesn't make sense, we don't. That's what happened with gitlab. Now to me it seems that you're basically saying you do what you want, i'll keep using my stuff. Which i find sad since it's creating artificial barriers between you and my :/ It also puts the discussion about a possible switch to gerrit in a weird situaion since we either all switch and have uniformity or we don't and then we end up with reviewborad+gerrit :/ Personally, I don't see why its a bad thing to have two options, if both fulfill a different users needs. Reviewboard is apparently liked by some, and its certainly simple to send trivial patches with it. Gerrit otoh is much better for people who work a lot on projects, as you can get much more productive with it. You just use git, and the rest is handled by the web ui. I've already written it in lots of places but i'll try to do it again: * Makes it harder for newcomers (and developers in general) since they have to find out which of the two patch review systems to use for repository * People need to llearn two tools instead of one to contribute patches to KDE projects * Increases our maintaince effort (there's two web systems that can break instead of one) And i could find more, but i sincerely think these three are bad enough. Cheers, Albert So, basically, from my point of view -- the tools are here, the CI is done.i That CI bits in particular make the workflow much more appealing to me. Now it's up to the KDE developers to come to a decision whether they want that or not. Maybe you could start a thread explaining why gerrit is better than reviewboard nd why should we switch to it? I can just say that I like using it in the setup they have for Qt. Much more productive to work on patch sets and then pushing them to an alias remote. Then I can fix them up and/or rebase and push again to update everything. With reviewboard, I'd need to manually push each individual patch, and updating them is again as much work. Bye
Re: libkgeomap
El Diumenge, 14 de desembre de 2014, a les 18:57:44, Tobias Leupold va escriure: Hi list! recently, I requested to move libkface from extragear/libs to to kdegraphics/libs, because KPhotoAlbum began to use it as the first non-Digikam program. This has been done in the meantime and now, we have a Digikam- independent libkface release to be found in unstable/applications (which can be used by distributors to create Digikam-independent libkface packages). Thanks again for the move :-) Recently, we started to use another library from Digikam in KPhotoAlbum, libkgeomap. Would it be possible (of course after some review etc.) to do the same with this library, for the same reasons? Probably, kdegraphics/libs would not be the right place for libkgeomap, as it depends on Marble, but kde-edu. Gilles Caulier from Digikam recently suggested that I asked for that, because apparently a lot of patching has been done to libkgeomap so that a stand-alone library release would be possible. I'm sure that the libkgeomap maintainers (esp. Gilles Caulier) will gladly change what has to be changed to get an independent release, and we would get the same benefits of it as the libkface move made. What do you think? What does libkgeomap do? Cheers, Albert Cheers, Tobias
Re: libkgeomap
libkgeomap is a wrapper between marble for local map, OpenStreetMap, and GoogleMaps, to display geolocated items place over a world map. A widget is provided, and collection of tools to process : - Reverse Geocoding, - Tracks management, - Selection over map to process searches. It used in digiKam to : - show geolocation info about selected items from icon view, - show a map with region selector to process searches - show a big map view to replace icon-view by a map with all items superimposed. It used too, in kipi-plugins with GPSSync tool to : - Correlate items with a GPX track - Made GPS track - Perform reverse Geocoding using Internet server. Project page : https://projects.kde.org/projects/extragear/libs/libkgeomap API Doc : http://api.kde.org/extragear-api/libs-apidocs/libkgeomap/libkgeomap/html/index.html Gilles Caulier 2014-12-15 21:46 GMT+01:00 Albert Astals Cid aa...@kde.org: El Diumenge, 14 de desembre de 2014, a les 18:57:44, Tobias Leupold va escriure: Hi list! recently, I requested to move libkface from extragear/libs to to kdegraphics/libs, because KPhotoAlbum began to use it as the first non-Digikam program. This has been done in the meantime and now, we have a Digikam- independent libkface release to be found in unstable/applications (which can be used by distributors to create Digikam-independent libkface packages). Thanks again for the move :-) Recently, we started to use another library from Digikam in KPhotoAlbum, libkgeomap. Would it be possible (of course after some review etc.) to do the same with this library, for the same reasons? Probably, kdegraphics/libs would not be the right place for libkgeomap, as it depends on Marble, but kde-edu. Gilles Caulier from Digikam recently suggested that I asked for that, because apparently a lot of patching has been done to libkgeomap so that a stand-alone library release would be possible. I'm sure that the libkgeomap maintainers (esp. Gilles Caulier) will gladly change what has to be changed to get an independent release, and we would get the same benefits of it as the libkface move made. What do you think? What does libkgeomap do? Cheers, Albert Cheers, Tobias
Re: libkgeomap
El Dilluns, 15 de desembre de 2014, a les 21:57:05, Gilles Caulier va escriure: libkgeomap is a wrapper between marble for local map, OpenStreetMap, and GoogleMaps, to display geolocated items place over a world map. A widget is provided, and collection of tools to process : - Reverse Geocoding, - Tracks management, - Selection over map to process searches. It used in digiKam to : - show geolocation info about selected items from icon view, - show a map with region selector to process searches - show a big map view to replace icon-view by a map with all items superimposed. It used too, in kipi-plugins with GPSSync tool to : - Correlate items with a GPX track - Made GPS track - Perform reverse Geocoding using Internet server. So kipi-plugins depends on digikam? Random questions: * Where does marble come in? * How is google maps handled? AFAIR you can't just embed it like that in an app. Cheers, Albert Project page : https://projects.kde.org/projects/extragear/libs/libkgeomap API Doc : http://api.kde.org/extragear-api/libs-apidocs/libkgeomap/libkgeomap/html/ind ex.html Gilles Caulier 2014-12-15 21:46 GMT+01:00 Albert Astals Cid aa...@kde.org: El Diumenge, 14 de desembre de 2014, a les 18:57:44, Tobias Leupold va escriure: Hi list! recently, I requested to move libkface from extragear/libs to to kdegraphics/libs, because KPhotoAlbum began to use it as the first non-Digikam program. This has been done in the meantime and now, we have a Digikam- independent libkface release to be found in unstable/applications (which can be used by distributors to create Digikam-independent libkface packages). Thanks again for the move :-) Recently, we started to use another library from Digikam in KPhotoAlbum, libkgeomap. Would it be possible (of course after some review etc.) to do the same with this library, for the same reasons? Probably, kdegraphics/libs would not be the right place for libkgeomap, as it depends on Marble, but kde-edu. Gilles Caulier from Digikam recently suggested that I asked for that, because apparently a lot of patching has been done to libkgeomap so that a stand-alone library release would be possible. I'm sure that the libkgeomap maintainers (esp. Gilles Caulier) will gladly change what has to be changed to get an independent release, and we would get the same benefits of it as the libkface move made. What do you think? What does libkgeomap do? Cheers, Albert Cheers, Tobias
Re: libkgeomap
2014-12-15 22:01 GMT+01:00 Albert Astals Cid aa...@kde.org: El Dilluns, 15 de desembre de 2014, a les 21:57:05, Gilles Caulier va escriure: libkgeomap is a wrapper between marble for local map, OpenStreetMap, and GoogleMaps, to display geolocated items place over a world map. A widget is provided, and collection of tools to process : - Reverse Geocoding, - Tracks management, - Selection over map to process searches. It used in digiKam to : - show geolocation info about selected items from icon view, - show a map with region selector to process searches - show a big map view to replace icon-view by a map with all items superimposed. It used too, in kipi-plugins with GPSSync tool to : - Correlate items with a GPX track - Made GPS track - Perform reverse Geocoding using Internet server. So kipi-plugins depends on digikam? Random questions: * Where does marble come in? It's a external dependency from KDE-edu. We use marble widget. * How is google maps handled? AFAIR you can't just embed it like that in an app. Through Khtml currently. For KF5, we will port to webkkit as well. Gilles Caulier
Re: libkgeomap
2014-12-15 22:01 GMT+01:00 Albert Astals Cid aa...@kde.org: El Dilluns, 15 de desembre de 2014, a les 21:57:05, Gilles Caulier va escriure: libkgeomap is a wrapper between marble for local map, OpenStreetMap, and GoogleMaps, to display geolocated items place over a world map. A widget is provided, and collection of tools to process : - Reverse Geocoding, - Tracks management, - Selection over map to process searches. It used in digiKam to : - show geolocation info about selected items from icon view, - show a map with region selector to process searches - show a big map view to replace icon-view by a map with all items superimposed. It used too, in kipi-plugins with GPSSync tool to : - Correlate items with a GPX track - Made GPS track - Perform reverse Geocoding using Internet server. So kipi-plugins depends on digikam? No. kipi-plugins and digiKam depends of libkgeomap which host common implementations. Gilles Caulier
Re: [Kde-pim] Problems with infrastructure
Martin Klapetek wrote: Our very own manifesto, which we've established not so long ago, does not dictate that a project must be kf5 or kdelibs based application to be considered a KDE project. But there *is* an expectation that the projects use KDE infrastructure, so the implication in I also admit that I would probably feel a little bit sad if Trojita ended up to be the only project which sticked with Gerrit (Jan Kundrát) that it would keep using Gerrit no matter what KDE decides to use officially does not fit into that. That creates the situation that we either all switch and have uniformity or we don't and then we end up with reviewborad+gerrit (Albert Astals Cid), which to me sounds a lot like blackmail (of course not by Albert, he's just the messenger). Kevin Kofler
Re: [Kde-pim] Problems with infrastructure
Hi all, Going to reply to all the various bits and pieces that have been mentioned in order now. Apologies for the long mail. For deleting branches, I think we can allow this - given some protection for certain branches (like the KDE/* branches for instance). Note that courtesy of the backup functionality in our hooks, no branch or tag is ever truly deleted from a repository on git.kde.org. I don't know how easy it would be to alter this behaviour based on the account name of the developer. In terms of tools: for both clear messaging, and to minimize maintenance effort we need to have just a single tool. It isn't just the tool itself which has to be maintained: we have commit hooks, integration with other bits of infrastructure and so forth which also needs to both be implemented and maintained. The more custom work we have, the harder it is to upgrade things. We'll confuse newcomers if projects A, B and C are reviewed on tool X while projects D, E and F are reviewed on tool Y. A single tool would be best here. Let me make clear that it is not a case of Reviewboard vs. Gerrit here - as other options need to be evaluated too. In regards to the difficulty of Gerrit - I tend to agree with this argument (it took me at least a minute to find the comment button, and I didn't even get to reviewing a diff). Plus there are major concerns with integration into our infrastructure, such as pulling SSH keys from LDAP for instance (no, you can't have the tool maintain them itself - as mainline Git and Subversion need the keys too). In terms of Reviewboard statistics - I don't have those to hand. Someone would need to come up with some scripts which could be run against the web server logs to generate some numbers here. We do have the logs though. Please note that any discussion of tools should be on the merits of the tools themselves. Things like CI integration are addons, which both Reviewboard and Gerrit are capable of. The only reason we don't have Reviewboard integration yet is a combination of technical issues (lack of SNI support in Java 6) and resource ones (some projects take a long time to complete, and i'm concerned we don't have the processing power). In terms of a modern and consistent project tool - I agree here. A long term todo item of sysadmin is to replace projects.kde.org. The question is of course - with what. Chiliproject is now unmaintained, so we do have to migrate off to another solution at some point. If the new tool happens to be more integrated in terms of code review, that is a bonus from my point of view (as it means the integration will be better, and there is one less piece of infrastructure to maintain). Thanks to Luca, we have a list of possible options to review. Contact has already been made previously with the Gogs developers, so it is possible they would be amenable to making changes necessary to support what we need. Phabricator is also interesting, although we may have to overcome some barriers with callsigns due to the sheer number of repositories we have. It's code review tool is similar to Reviewboard, but it has a much more sophisticated CLI client you can use. If anyone has any other possible solutions, I would like to hear about them as well. @Jan: could you please outline what you consider to be the key advantages? At the moment I understand that you are after: 1) CI integration to pre-validate the change before it gets reviewed 2) Ability to directly git pull the patch (which Phabricator's arc tool would meet I believe?) Thanks, Ben
