Hi All,
To add my 2c to a number of posts above, taking advantage of my timezone to be able to summarise :-):
When you provide code to open source, in a sense, you no longer "own" the code, the purpose of open sourcing is to allow others to use and abuse it.
However as Colomban says, maintainers have accepted a *responsibility* for a piece of code. With that responsibility must come an ability to actually perform the tasks required. Allowing anyone to commit any change without maintainer input just makes life harder for the maintainers and since they are all volunteers with limited time this is bad.
Of course on the other hand because the maintainers are volunteers with limited time this process slows changes, but IMHO this is necessary. Having more maintainers for a piece of code is of course the solution, but as we are finding, its hard to actually do for a small project. Even for core there was a deafening silence when I recently suggested that more people volunteer to be maintainers.
Of course the Geany community also has a responsibility to Geany users (not least ourselves :-) to make sure that the whole Geany ecosystem offered as an "official" release meets reliability and usability standards. On this basis, Frank's concern that some plugins don't meet those standards is important, but I don't think that it is reasonable for the community to impose work on maintainers without discussion (thats this thread) and a reasonable period for improving things, otherwise the community is undermining the maintainers responsibility, and I certainly would get upset if I were a maintainer.
Also just outright disabling plugins is doing the users a disservice since the community doesn't know how the plugin is used and how important its capabilities may be to users, and as Colomban noted it reduces testing. If plugins are not maintained (ie no one volunteers) they should eventually be removed, but only if they don't meet the criteria, and not without a reasonable period of deprecation for users to note their interest and either volunteer themselves, or persuade someone that its worth doing (or there is an alternative like the debugger). Here Geany has an advantage since all its users are programmers, though not all are C programmers.
Instead I suggest that plugins that the community knows meet the criteria be marked in some way (starred?) on the plugin manager so that the user can see it, rather than the plugin be disabled. In other words meeting the criteria is rewarded rather than not meeting them being punished. The purpose after all is to improve plugins so we can all use them. And deprecated plugins can also be marked (!) to warn that they may be removed from releases soon if no one wants to support it.
I did think of having the plugin manager provide a popup saying something like "this plugin is not known to meet the Geany standards, do you want to continue" the way some other applications do, but in reality the user has no basis for making such a decision at that moment and, anecdotally at least, most (me too) just click continue without thought. So its really just a waste of time doing this.
As to what the criteria for a star might be, I suggest:
Must meets:
1. No unresolved reported stoppers ie crashes, freezes or interference with Geany operation that risks users losing work. 2. No failures against an agreed set of tools and options 3. Basic user documentation
Nice to meets:
1. No false positives against the tools, but a code comment about why its a false positive might be acceptable if it can't be removed easily. 2. "Good" user documentation 3. No unresolved significant problems, ie those that stop the plugin from performing its documented function properly or that interfere with other Geany operation. 4. "Geany type" implementation, ie not using complex or memory hungry or cpu hungry methods when alternatives have been suggested (preferably as patches :-)
Not part of this criteria:
1. Improvements not implemented 2. Implementation methods
On the tools suggested so far my comments:
gcc - same flags as Geany cppcheck - used it successfully on c++, never tried on C clang - worthwhile, more picky than gcc valgrind - *must* be used with GTK suppression and may need others, useful, but potential for lots of maintenance headaches.
I havn't used any of the other tools.
On code style, Geany has a code style and some Perl scripts to aid in meeting it. Having the plugins meet this style would help reviewers, but may be a problem for a main maintainer if they are used to something else (I had real problems with style when making changes to Geany when my day job code used a different style, but Nick was nice enough to add some of my most common errors to the Perl scripts) so enforcing a style may be counterproductive, I'd vote 1) against enforcing a particular style but 2) for plugins enforcing some style, and 3) encouraging that to be the Geany style.
On which VCS and associated process discussions, another thread please, not this one, its likely to be a long discussion :-) but as there is a hiatus now after 0,20 release its time to consider it again.
As to what I might do, I can review code/docs when I'm available, but I am aware that my available time is variable and can't be relied on to meet any specific schedule. And I also don't heavily use any plugins other than addons task list.
Cheers Lex