On Mon, 2008-02-25 at 09:30 +0000, Benjamin Otte wrote: > Havoc Pennington <hp <at> pobox.com> writes: > > > Wait, that's the whole point is to crash the app > > > > The issue is that if it just prints stuff, people don't fix the bug > > (in part, perhaps, because nothing goes through bug-buddy). Maybe the > > fix is to bug-buddy the warning, but don't crash the app. Not sure how > > hard that would be to code. > > > I guess this is the age-old question of "How should we treat a non-critical bug > during development?" > And I guess it is equivalent to "Should we enable gcc's -Werror switch for svn > builds?" which is the question I regularly clash about with Behdad. > > In the end it's a tradeoff. A tradeoff between forcing users to make you care > about potentially harmless stuff that's not "a real bug" (to quote Behdad) and > missing real bugs because users don't care about bugs that don't bite them. It's > also a tradeoff between allowing you to be lazy and not fix warnings immediately > - or at least until the next gcc comes around that makes them real bugs - and > having to fix obscure warnings on weird platforms immediately because they break > the build or prevent the application from running. Jumping in late on this conversation ... running from JHBuild I had to patch out the fatal warnings, because all sorts of apps I normally use *not from JHBuild* (Eclipse, Firefox, Pidgin, etc.) were dying from critical warnings caused by the application code, rather than bugs in the JHBuild built things. So, I'm not sure that the fatals warning has the intended effect of "catch problems", it may just have the unintended effect of driving people away from testing the unstable code at all. - Owen
Attachment:
signature.asc
Description: This is a digitally signed message part