Re: [Geany-devel] Third party plugin publish and third party library bundle problem
On 2012/7/15 20:28, Frank Lanitz wrote: On Sun, 15 Jul 2012 21:56:32 +1000 Lex Trotman ele...@gmail.com wrote: BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included. Yes. I missed that too. Most plugins are GPL2+ so it needs to be also GPL2+... BSD should also be fine in most cases. But LGPL could be problematic. I prefer Simplified BSD License for this plugin. What do you mean it should be fine for most cases? Could you explain more? Thanks, Hong ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Third party plugin publish and third party library bundle problem
On 2012/7/15 21:21, Thomas Martitz wrote: Am 15.07.2012 14:26, schrieb Frank Lanitz: On Sun, 15 Jul 2012 19:01:53 +0800 Hong Xu d...@hong.me wrote: On 07/15/2012 03:40 PM, Frank Lanitz wrote: On Sun, 15 Jul 2012 09:27:46 +0800 Hong Xu d...@hong.me wrote: And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers. IIRc this was under discussion in past but was dismissed due to adding complexity and little overall understanding of this. However, I don't think cloning the repository is this much traffic. Also a goal was to have plugins and its patches being reviewed before entering master to enforce a minimum on quality. This also includes some fire-and-forget-plugins of some developers as you can see from MAINTAINERS files there are a lot of plugins out of maintenance. Thanks. However, I have to make a pull request for any trivial changes in this way. Do you think this is unnecessary? We are still in finding a good flow on this as I agree its not optimal. Most of the time changes are not actually trivial. Also multiple small and trivial changes can be submitted as a single pull request. Anyway this is the linux kernel dev model and it works good (for some projects) even if tiny changes need to go through the chain as well. OK, that should be fine. Hong ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Third party plugin publish and third party library bundle problem
Am 16.07.2012 16:41, schrieb Hong Xu: On 2012/7/15 20:28, Frank Lanitz wrote: On Sun, 15 Jul 2012 21:56:32 +1000 Lex Trotman ele...@gmail.com wrote: BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included. Yes. I missed that too. Most plugins are GPL2+ so it needs to be also GPL2+... BSD should also be fine in most cases. But LGPL could be problematic. I prefer Simplified BSD License for this plugin. What do you mean it should be fine for most cases? Could you explain more? The 2-clause BSD is always fun. As is LGPLv2+. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Third party plugin publish and third party library bundle problem
On 2012/7/15 19:56, Lex Trotman wrote: On 15 July 2012 21:03, Hong Xu d...@hong.me wrote: On 07/15/2012 07:01 PM, Hong Xu wrote: On 07/15/2012 03:40 PM, Frank Lanitz wrote: On Sun, 15 Jul 2012 09:27:46 +0800 Hong Xu d...@hong.me wrote: And, BTW, why geany-plugins project doesn't use a submodule for each plugin? Not all people need to clone the whole repository, and as it is separated to submodules, the permission control can be better for developers. IIRc this was under discussion in past but was dismissed due to adding complexity and little overall understanding of this. However, I don't think cloning the repository is this much traffic. Also a goal was to have plugins and its patches being reviewed before entering master to enforce a minimum on quality. This also includes some fire-and-forget-plugins of some developers as you can see from MAINTAINERS files there are a lot of plugins out of maintenance. Thanks. However, I have to make a pull request for any trivial changes in this way. Do you think this is unnecessary? In you mind, is there any advantages for geany plugins in this repo other than other places? Sorry, any *other* besides the quality enforcement? Well, of course the geany-plugins is packaged for at least some distros, in particular debian and ubuntu. That will of course get greater exposure, and maybe contributions, and also maybe bug reports :) BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included. The library is here: https://github.com/editorconfig/editorconfig-core It is released under Simplified BSD License. So I believe this is not an issue. Hong ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Third party plugin publish and third party library bundle problem
On 2012/7/15 15:49, Frank Lanitz wrote: On Sat, 07 Jul 2012 13:39:56 +0800 Hong Xu d...@hong.me wrote: Whatever the answer is, can I put my plugin in https://github.com/geany/geany-plugins ? This repository seems better maintained than mine. I didn't have a look onto you code by now but in general you can add you plugin also to geany-plugins project. I'd prefer you to having you own fork of plugins and sending pull request against geany/geany-plguins/master The second problem is that, how should I bundle a third party C library with my plugin? I think Matthew answered here very well. It really depends on how common this library is or if you are patching it in some kind. Well... I don't like shipping to much libraries with one plugin as there is always an question of updates in terms of a security fault etc. Also this might could cause ending up in typical Windows scenario where you are might having GTK installed about 1000 times - each GTK serving its own application. So: if the library is typical packaged for target platforms or if its available via a common way (e.g. ppa on Ubuntu, some of the rpm-pages for SuSE or Fedora/RH/SL) and you don't have any patches inside I wouldn't deliver it with the plugin but depend on it. Currently, the library is not commonly distributed under common distributions. The library URL is: https://github.com/editorconfig/editorconfig-core There's a problem here: the library build system is based on CMake, while the geany-plugins project supports both autotools and waf. If I want to include the source in my code, I would probably have to reproduce the cmake build system using autotools. Do you have any suggestions handling a CMake third party library in geany-plugins? And do I also need to support BOTH the two build systems? Hong ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Dropping Waf support?
Hey all, this topic has been brought up already a couple of times, for example on [1]. What do you think about dropping Waf support in Geany and in the Geany-Plugins project? While I was defending Waf in Geany, I somewhat changed my mind. Not because I don't like it anymore, but I increasingly see the efforts in maintaining two (to be exactly three for Geany) build systems is too much. Since the make/MSYS build system support seems to get better and better due to Nick's and Dimitar's work on it, I thought about dropping the Waf support. It seems nobody knows it well enough and probably except for a few users nobody is using it. (And obviously I don't do so much anymore and also lost a bit interest in maintaining forever.) The other thing is that Waf causes often problems for distro packages, especially for the Debian folks [2]. So, I'd go the easy way in this case and just remove Waf. Then we only need to maintain the autotools based build system for non-Windows systems and the make based for Windows. For Geany-Plugins, we would need to get something working on Windows but maybe we could re-use Geany's make based system for Windows here. What do you guys think? [1] http://sourceforge.net/tracker/index.php?func=detailaid=3460449group_id=153444atid=787794 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645190 Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc signature.asc Description: OpenPGP digital signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Third party plugin publish and third party library bundle problem
On Mon, 16 Jul 2012 16:59:12 +0200 Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 16.07.2012 16:58, schrieb Thomas Martitz: Am 16.07.2012 16:41, schrieb Hong Xu: On 2012/7/15 20:28, Frank Lanitz wrote: On Sun, 15 Jul 2012 21:56:32 +1000 Lex Trotman ele...@gmail.com wrote: BTW you mentioned a third party library, but you didn't say what library. It would of course have to have a suitable license to allow it to be included. Yes. I missed that too. Most plugins are GPL2+ so it needs to be also GPL2+... BSD should also be fine in most cases. But LGPL could be problematic. I prefer Simplified BSD License for this plugin. What do you mean it should be fine for most cases? Could you explain more? The 2-clause BSD is always fun. As is LGPLv2+. s/fun/fine/ :) Rethinking about . well, you might are correct. In terms of distribution as we most likely will do, LPGL should also be fine. Sorry - my fault. In terms of BSD I'm thinking about some special parts e.g. calling author's names inside credits I saw in past. But should not be apply able on our case Cheers, Frank -- http://frank.uvena.de/en/ pgpXZbmoQPcMW.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Third party plugin publish and third party library bundle problem
On Mon, 16 Jul 2012 23:13:55 +0800 Hong Xu d...@hong.me wrote: On 2012/7/15 15:49, Frank Lanitz wrote: On Sat, 07 Jul 2012 13:39:56 +0800 Hong Xu d...@hong.me wrote: Whatever the answer is, can I put my plugin in https://github.com/geany/geany-plugins ? This repository seems better maintained than mine. I didn't have a look onto you code by now but in general you can add you plugin also to geany-plugins project. I'd prefer you to having you own fork of plugins and sending pull request against geany/geany-plguins/master The second problem is that, how should I bundle a third party C library with my plugin? I think Matthew answered here very well. It really depends on how common this library is or if you are patching it in some kind. Well... I don't like shipping to much libraries with one plugin as there is always an question of updates in terms of a security fault etc. Also this might could cause ending up in typical Windows scenario where you are might having GTK installed about 1000 times - each GTK serving its own application. So: if the library is typical packaged for target platforms or if its available via a common way (e.g. ppa on Ubuntu, some of the rpm-pages for SuSE or Fedora/RH/SL) and you don't have any patches inside I wouldn't deliver it with the plugin but depend on it. Currently, the library is not commonly distributed under common distributions. The library URL is: https://github.com/editorconfig/editorconfig-core Based on that I think including would be fine. There's a problem here: the library build system is based on CMake, while the geany-plugins project supports both autotools and waf. If I want to include the source in my code, I would probably have to reproduce the cmake build system using autotools. Do you have any suggestions handling a CMake third party library in geany-plugins? And do I also need to support BOTH the two build systems? Well please include it to autotools if ever possible. Even cmake might have some advantages (cannot say) I don't see any chance in terms of man power etc to have it also maintained. Cheers, Frank -- http://frank.uvena.de/en/ pgpR64oy5iLaV.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Dropping Waf support?
Le 16/07/2012 19:36, Enrico Tröger a écrit : Hey all, this topic has been brought up already a couple of times, for example on [1]. What do you think about dropping Waf support in Geany and in the Geany-Plugins project? While I was defending Waf in Geany, I somewhat changed my mind. Not because I don't like it anymore, but I increasingly see the efforts in maintaining two (to be exactly three for Geany) build systems is too much. Since the make/MSYS build system support seems to get better and better due to Nick's and Dimitar's work on it, I thought about dropping the Waf support. It seems nobody knows it well enough and probably except for a few users nobody is using it. (And obviously I don't do so much anymore and also lost a bit interest in maintaining forever.) The other thing is that Waf causes often problems for distro packages, especially for the Debian folks [2]. So, I'd go the easy way in this case and just remove Waf. Then we only need to maintain the autotools based build system for non-Windows systems and the make based for Windows. For Geany-Plugins, we would need to get something working on Windows but maybe we could re-use Geany's make based system for Windows here. What do you guys think? I don't mind much, since I don't use Waf nor build on Windows myself. But yes, I agree that it Autotools and Windows-specific makefiles covers all platforms there is no need to maintain an N-th build system. This said, the only time I wanted to build on Windows I used Waf -- though I haven't even tried the specific makefiles. So I don't mind, but I probably won't maintain Waf either because of a lack of interest and knowledge. My 2¢. Regards, Colomban [1] http://sourceforge.net/tracker/index.php?func=detailaid=3460449group_id=153444atid=787794 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645190 Regards, Enrico ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel