[Geany-devel] Ideas on increasing quality of plugins

Colomban Wendling lists.ban at xxxxx
Tue Feb 22 22:26:33 UTC 2011


Le 22/02/2011 22:30, Thomas Martitz a écrit :
> 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 don't think so. In general, open source projects are maintained by a
few people that know (and hopefully trust) each other (hey, at least
they worked together for a while) and third-party code is contributed by
patches the maintainers have a chance to review.
So it's not exactly the same picture here I think since we have one
repository for several projects.

What I mean is basically: I personally would welcome any patch and be
happy to review it, but I would not accept the same code changes to
happen without asking me. This is NOT an arrogant position, it's more a
matter of responsibility: if somebody is the maintainer of something,
she must accept the changes made to that thing, because she'll be
responsible of what happens if the change was bad.

This is exactly the same picture that sometime can be seen in OSS
projects when proposing a patch that introduces large change: the people
might appreciate it, but they gotta maintain it, or know you'll be still
around to maintain it over time. So maybe they will refuse it only
because of the maintenance overhead. It's maybe sad, but not necessarily
unwise.

> 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).
I understand your purpose, but I doubt that such a policy would please
anyone.
Yes, I agree that IF the people that commit those fixes you talk about
are only the ones that are competent to do so, it'd be acceptable IMHO.
But with such policy it's likely that at some point somebody will feel
too confident and "fix" somebody else's code wrongly. And there will be
the drama, the hard feelings and the collapsing of the whole project --
I know, it's a pessimistic POV :D


Cheers,
Colomban



More information about the Devel mailing list