[Geany-devel] Ideas on increasing quality of plugins

Lex Trotman elextr at xxxxx
Sat Mar 12 01:37:14 UTC 2011

>>>> The general consensus seemed to be to not disable plugins from the
>>>> nightly builds or SVN just because they fail some tests, so these will
>>>> have to all be warnings.
>>> It's a bit more complicated IMO: if these warnings are on by default in
>>> everyone's build, a code failing with them would just be as invalid as
>>> an invalid C code (e.g. breaks everyone's build, and isn't acceptable at
>>> all).
>> Well on the development code base warnings should not break the build,
>> if they do thats another problem :-)
> ...and invalid C code should neither, but it does :(

Hmmm, that IS a problem, do we know why? Is make -k sufficient to fix
it?  (Sorry I can't try building things on this machine so I can only
ask the question)

> What I mean is that it is acceptable IMO to consider some "mistakes" as
> "invalid syntax".

Maaaybe, sort of see your point, but not really convinced that
uprating warnings to errors is a good idea on the dev codebase, it
stops people trying and testing things.

>>  In fact even errors should also
>> not break the whole build, just the specific plugin.
> agreed. But that's a somewhat different point I guess... maybe just tell
> people to use `make -k` ^^


>>> The problem here is that there is currently a plugin that can't be
>>> compiled with them, so enabling them would mean disabling the plugin
>>> that used to build.
>>> Maybe the solution is to wait for Alexander to fix these problems, and
>>> then enable the "errors".
>> But the next patch commit on any plugin could fail one of the checks,
>> so then the whole dev build fails again, thats no good, its got to
>> still build with warnings, its a development build after all.
> but again, what if I add
>  hello guys!
> in the middle of the code?
> Or even more realistic (someone might even understand... :D)
>  if some test { foo_bar(); }
> In this case, what would you do? Blame the programmer most probably. And
> you'd be right IMO :)

Of course it should fail the plugin, but as above, not the whole build.

And I hope we use "blame" in the non-emotive sense of "identify the
cause of the problem" :-)


> Cheers,
> Colomban

More information about the Devel mailing list