[Geany-devel] Ideas on increasing quality of plugins

[Thomas Martitz]

Am 22.02.2011 21:40, schrieb Colomban Wendling:
> Le 22/02/2011 20:04, Thomas Martitz a écrit :
>> Am 22.02.2011 19:36, schrieb Colomban Wendling:
>>
>>>> So my 1st suggestion is to remove all plugins which do have known issues
>>>> and don't compile with some -W-flags (needs to be defined) from common
>>>> build until these are fixed. Also remove plugins which don't bring
>>>> propper documentation as well are unmaintained for some time.
>>> Well... I'm puzzled. Disabling unperfect plugins is a good idea in
>>> theory for the stability of Geany, but... how would be plugins tested
>>> then?
>>>
>>> However, I agree with making official builds with strong error checking
>>> enabled (at least -Werror-implicit-function-declaration comes directly
>>> to my mind). This is static checking that will show most obvious
>>> problems, and hopefully it'll encourage their maintainer to fix them.
>>> However, finding the right flags will not be easy... for example not
>>> allowing any implicit cast may have a false-positive effect where
>>> unexperimented developers might hide a part of those with a cast where a
>>> proper fix would be better.
>> I agree. While we may know they have known problems, how would we know
>> in the future if they're disabled and receive no testing?
>>
>> I think all plugin developers should get more easy about others touching
>> there code. I could probably fix a number of problems in other people's
>> plugins, but I'm afraid of the surrounded discussion (post or pre commit).
> I don't think that touching other one's code without her agreement is a
> good idea. There are several reasons for this that comes to mind:
> * some people will find this offensive (e.g. "you can't even code right
> and you won't even understand if I tell you");
> * some people will find it cool, but won't necessarily try to understand
> any further (heh, it's already fixed), so would likely reproduce
> mistakes later;
> * and unfortunately, some people might change things with not enough
> care or understanding and break other things -- this is easier than we
> might think...
> * and some people would not feel confident of somebody else commit --
> and this would probably be my case if it's somebody I hardly know.
>
> And AFAICT, people who would need help are generally likely to accept it
> when proposed (probably more than if it was imposed).
>

It's all open source after all, and part of it is working together with 
others on the same code. All of your points contradict with that spirit.

I didn't mean to say I would like to do work on someone else's plugin 
(as in new features). Just fix the most immediate problems. If the fix 
not a few-liner or no brainer I wouldn't bother with it any further 
anyway (but instead just disable the plugin for the time being).

Best regards.