On 03/11/11 15:27, Frank Lanitz wrote:
On Wed, 23 Feb 2011 12:41:54 -0800 Matthew Brushmatthewbrush@gmail.com wrote:
- 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.
How this is going to be maintained? Somebody has to take over responsibility to set the flag.
I would be willing to perform certain checks on a few of the plugins (at least the ones that don't require tons of coding expertise), and if a few other people volunteered, it wouldn't be much of a job. Even if it's not as formal as the previous discussions, just an email notifying the plugin author that one of these criteria is not met, just as an example:
- Up to date documentation with the things from my last message, for example - Proper license/license file - Passes some checks such as 'cppcheck' being discussed on the ML. - Performs its purpose without dumping errors on the console/segfaulting/etc.
I guess just to have someone else confirm these things. For example with the Devhelp plugin I wrote, I don't even really know if it works/installs on anyone else's computer except mine. I'm not sure if anyone is using it, or anyone (besides yourself) has even tried it. For all I know, everyone compiling from source could be disabling my plugin because of errors or something. I would be glad to have a 2nd set of eyes just give it a quick once over it to make sure it's installing and serving its purpose as expected and the documentation isn't out of date, and so on, on a regular basis.
Maybe it's too much work, but it seems possible.
Cheers, Matthew Brush (codebrainz)