[Geany-devel] Ideas on increasing quality of plugins

[Lex Trotman]

On 12 March 2011 12:53, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
> 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?

I agree that warnings should be fixed, but...

Not only the developer is going to be using the plugins, people who
are testing or even just using the latest will be, so you screw them
up as well as the original developer :-(

And also these users should not need the testing tools installed to
compile, we don't want to increase the dependencies.

And as for the original developer, they now have to build in the same
way & use the same testing tools.  That assumes they are using the
same environment as the nightly builds, and I am not sure I even know
exactly what that is.

Remember I'm only talking about development, I think the community has
a right to ask for a higher standard for releases that the community
is putting its name to.  But during development, preventing compiling
perfectly legal but frowned on code, is an imposition that I don't
think the community currently wants to make (based on other comments
in the thread).


>
>>>>  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"...

Yes, on the grounds that our worldwide army of automatic beating down
robots has not been deployed yet, I guess we have to fall back to this
:-)

Cheers
Lex

>