I'm no plugin creator (yet), and as such probably can't provide any valuable insights here, but nevertheless, here goes...
Maybe, the plugin creators themselves could decide if they wanted to be added to this central plugin scheme. And if a plugin creator doesn't want that, he can just as well keep his own build system and make releases on his own, so the users of his plugin can install at their leisure. The downsides of this will be known, as the end-user will most certainly have a more difficult time getting the plugin and keeping it up to date (hail packages!).
So the way I see it, it's not an either-or situation, just a logical or situation (note that I didn't say xor ;) ).
Kind regards, Nicolas
2009/6/3 Enrico Tröger enrico.troeger@uvena.de
Hey,
yesterday, I talked to Chow Loong Jin on IRC about the whole recent plugins release issues and we came across an interesting question about restructuring the whole way how we organise our external plugins currently.
We once said, plugins should be and keep independent so they can installed on their own and without the need to install all other plugins. Therefore, currently each plugin (those in the geany-plugins project) have an own build system, based on autotools. Additionally we have a common build system, based on waf, which one can use to build all plugins at once from SVN.
While discussing how a possible geany-plugins release could be done and what's necessary, we came across the idea of changing the above idea: give up the independence of each plugin and instead create one big project consisting of the various plugins but with only one build system. Following you'll find a list of pros and cons which instantly came to my mind as some kind of rationale.
Pros:
- easier developing for plugin authors, no need to fiddle with the own
build system, no stress about creating releases, you can just concentrate on coding
- one central po/ directory with translations of all plugins which
makes it much easier for translators so we hopefully get more translations for the plugins
- just one global build system, easier for developers, release manager
and users
- with Chow Loong Jin we get a release manager who takes care of
creating releases and their coordination
Cons:
- we loose the independence of plugins, i.e. plugins can't be released
on their own anymore or at least it gets harder to do so
- we will end up with one big geany-plugins release which probably
contains more plugins than users generally want/need (however the build system should allow users to exclude certain plugins from being built and automatically exclude those which can't be built due to missing dependencies)
- plugins (rather plugin releases) get dependent of other plugins and
their authors and after all, dependent of the release manager
One more note about translations: Yesterday, Frank mentioned he succeeded in writing a script to manage a global gettext system for plugins by copying and merging the individual message catalogues. However, this is of course just some kind of hack and far away from a clean solution. So, this is both, an argument for and against the above idea. It could be a workaround if we keep the current way of managing plugins, OTOH it shows the advantages of changing the handling.
So, you'll see this is some kind of basic question about the future of our plugins organisation. And because this affects all further actions, I'd like to hear your feedback first before continuing the other recent thread. Thanks.
I ask especially all current plugin authors for their opinion since this affects you directly. We don't want to decide anything without and force you to anything you don't want.
Raise your voice. Thanks.
I personally am not yet completely done with my decision as I still think separated, independent plugins is a good idea. But on the other hand, the advantages like the better translation coordination and the loss of responsibility of creating releases tempts me to change my mind (I don't like creating releases :D).
Regards, Enrico
P.S.: sorry for the mass of text, I tried to keep it short but obviously failed :(.
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel