On 12 March 2011 12:53, Colomban Wendling lists.ban@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