[Geany-devel] Ideas on increasing quality of plugins

Colomban Wendling lists.ban at xxxxx
Sat Mar 12 01:53:47 UTC 2011


Le 12/03/2011 02:37, Lex Trotman a écrit :
>>>>> 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.
Unfortunately, believe me that non-fatal warnings are use to be ignored
by unexperienced programmers, believing that if their code compile it is
then OK.
And I don't see why a warning upgraded to an error on every build would
be worst than a syntactical problem (as I described above previously)?
In a typical situation, the developer who writes the plugin should get
the warning (well, the error), see his plugin don't build, care
(hopefully :D), and then fix it directly even before committing and then
before anybody else could face the problem.
Don't you think?

>>>  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` ^^
> 
> Yep.
> 
>>
>>>> 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" :-)
Maybe my English knowledge is not good enough, but I meant "beat down to
death" :D [1]

Cheers,
Colomban


[1] hopefully the reader will see the humor and understand I actually
meant something like "gently ask the programmer to fix the problem"...



More information about the Devel mailing list