Hi all,
For first thing, maybe we could enforce use/passing of those tools mentioned and these before adding to release, examples: http://www.splint.org/ http://valgrind.org/info/tools.html (suppression for GTK - http://people.gnome.org/~johan/gtk.suppression) http://www.gnu.org/software/indent/ (just for making coding styles more consistent between plugins) http://check.sourceforge.net/ or http://cutest.sourceforge.net/ or http://cunit.sourceforge.net/ Perhaps some or all of these could be automated.
Another thing could be to make mandatory that documentation is existent and current, up to some standard. I mean for README, manual, and also doc-comments in code (ex. each function/global must have a comment or something). Some other items where documentation could be enforced; new keybindings, preferences, menu/toolbar items, tabs.
In reference to using additional languages for plugins, I think this should be #1 priority for improving quality. Think about it like this; who writes plugins? Geany users/hackers. What languages do they use/know? Probably not C in a lot of cases (more likely Python, PHP, etc - of course I'm just guessing on this). To make a PHP programmer write a plugin in C is asking for trouble (unless they know C also). If you could use a scripting language like Python, it would basically totally eliminate crashing Geany. I can't think of anything you could do in plain Python that would crash the interpreter all-together (thought it might be possible).
Of course this brings back the problem of the plugin API not being well-suited to use in other languages (no shared library to link to, no way to auto-generate the large bindings required, having to maintain backwards compatibility, etc). I was the one working on GeanyPy to try to add Python bindings but I all but gave up due to the above issues.
I think a big step forward would be to add the Geany Vala bindings into the official code distribution (adding to autotools/waf to put the VAPI into the right system location). Of course the Vala binding needs testing, but I can verify that it's very usable, having written some plugins with it. It won't get much testing unless it's part of Geany and mentioned in the Plugin documentation so people know it exists.
In the sense of VCS, I think using a more "social" site than SourceForge for the plugins could be helpful (I'm thinking GitHub, Gitorious, etc). There could be a geany-plugins repository that is the official one containing releasable code. There could be additional repositories each plugin author maintains against the official repository, where they make all their in-between release changes, and at release time, a pull request for each plugin could need to be sent to the official repository to bring in the releasable version. The benefit of this is also that you could hack on a plugin by forking it and then send a pull request to the person who maintains the plugin's repository for them to review, without messing with their code directly. (More info: http://help.github.com/pull-requests/) I know at least for GitHub, there is provided very pretty graphs and user interface which shows all issues, fork queue, pull requests, and other work being performed on the same code across repositories. This might be personal preference for workflow, because I'm not adept at using Subversion and I don't have access to make changes to the project at SourceForge, but it does seem to be the way the "cool kids are doing it" (ex. https://github.com/mirrors/linux-2.6).
Another slightly off topic thing that could be done is to make the plugins installable from within Geany where a releasable plugin hosted officially could be downloaded/updated by itself (kinda like Eclipse) without requiring all the stress of making a massive multi-plugin release for each Geany release. This would also make less work for whoever has to keep the build-systems up to date with the plugins. If the specific plugin author doesn't ensure their plugin builds properly, then people just won't be able to use that plugin. Also plugins could be fixed without waiting for release time.
Ok, I have typed too long now, so I will stop here :)
Cheers, Matthew Brush (codebrainz)