[Geany-devel] Ideas on increasing quality of plugins

[Matthew Brush]

On 02/23/11 04:28, Alexander Petukhov wrote:
> If nobody mind, let me state my opinions:
>
> 1. Maintaining
> I believe there has to be only one maintainer who is commiting code.
> As for me, the amount of code in a ordinary geany plugin is not that huge,
> one can easily support it. Others who has patches/improvements have to send them
> to the maintainer and it's he, who decides what to do with them and is somehow responcible for the result.
> Giving commiting rights to several people can cause mess in code.
Isn't this how the current setup is?  I thought it was just a courtesy 
to not mess with the other plugins?
> If the plugin is unmaintained for a long time, lets contact a developer to learn his plans
> and if he hasn't time for now (or at all) and there is someone else who wants to do his job - let this man to become a new maintainer,
> I think little developers will reject this suggestion if they really have no time to deal with the code for now.
> Current active maintainer have to mentioned on the plugins web-site in order to contact him to solve problems / send patches etc
>
> 2. Documentation
> Support Mathew, there has to be common documentation system,
> maybe we can start from standartization README etc standart files
Maybe even to have a "plugin template" (GStreamer has this[1]), where 
you clone from a repo/extract from a tarball all the standard files and 
then add your source code and customize the templates (README, autotools 
stuff, etc).
> 3. Different repos
> Here I strongly disagree, I think this will also cause kind of a mess,
> why not to solve problems in te common repository?
I guess I don't know enough about to Subversion to understand its 
workflow.  But this sounds better to me:

"The Fork + Pull Model lets anyone fork an existing repository and push 
changes to their personal fork without requiring access be granted to 
the source repository. The changes must then be pulled into the source 
repository by the project maintainer. This model reduces the amount of 
friction for new contributors and is popular with open source projects 
because it allows people to work independently without upfront 
coordination." [2]

But like someone said, this is a whole different thread, and I really 
don't know enough about VCS to have a strong opinion.
> 4. Removing unsupported plugins from releases
> what do you think about the following scheme: divide all pluging into:
> - "supported" (that are acting really well)
> - "unsupported" or "bad" (having problems) ?
> So, every geany-plugins release will contain several packages: "geany-plugins", "geany-plugins-bad or "geany-plugins-unsupported", something like this
This is like GStreamer plugins and I think it's a very good idea.  They 
could be grouped in the configure.ac file to add an option like 
--enable-bad and --enable--unsupported or something.
> 5. Other language bindings - don't really think it can increase plugins quality dramatically,
> there can be problems in any language that you have to solve in order to make your code work correctly.
I have to disagree with this for a few reasons:
   - Many more people would write plugins if they could do it in their 
"native" language (Just look at how many plugins Gedit has).
   - I'd rather use a plugin written in Perl by a Perl guru, running on 
it's interpreter, than Perl code written in C (ie. lets people use their 
existing skills instead of translating them into bad C code).
   - No memory leaks (ie automatic ref-counting, garbage collection)
   - Isolation from Geany since most languages would be running under 
their own VM/interpreter.  Same reason you don't often (or ever?) see 
Segmentation Fault when running a PHP or Python program for example.
   - Rapid development.  There's been many plugin ideas I've had myself 
that I would've written if I could've done it in a couple evenings 
instead of a month of evenings.
   - People can still use the C API.

The only downside I can think of is the extra memory overhead of the 
embedded interpreter.

My 0.02$

[1] 
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/chapter-building-boiler.html
[2] http://help.github.com/pull-requests/

Cheers,
Matthew Brush (codebrainz)