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