[Geany-devel] Ideas on increasing quality of plugins

[Lex Trotman]

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