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