Re: Reintroducing critical warnings?

["Havoc Pennington" <hp pobox com>]

Hi,

On Feb 19, 2008 6:31 PM, Bastien Nocera <hadess hadess net> wrote:
>
> On Wed, 2008-02-20 at 00:25 +0100, Vincent Untz wrote:
> > Le mardi 19 février 2008, à 23:46 +0100, Wouter Bolsterlee a écrit :
> > > 2008-02-19 klockan 21:20 skrev Christian Neumair:
> > > > I hereby propose to reintroduce the critical warnings we used to have
> > > > during unstable release cycles.
> > >
> > > Unstable gnome-session builds (eg. minor version is odd) set the G_DEBUG
> > > variable by default, so this should still work.
> >
> > Most distros have a patch to remove this "feature", though :/
>
> The problem is that it crashes the app when it prints a simple and
> usually harmless warning. It should just dump a backtrace instead, and
> the execution of the program carry on.
>

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.

It's always a bug if a GUI app is printing stuff on stderr (other than
usage(), perhaps). If there isn't a real problem then it's wrong to
clutter ~/.xsession-errors with crap. If there is a real problem, the
problem should be fixed and is a bug. So either printing stuff is a
bug, or the stuff printed points to a bug. But there's a bug.

I don't see why a distribution would turn off fatal warnings for an
unstable release. The point of an unstable release is to find bugs. So
if there's a bug, crashing to invoke bug-buddy and encourage fixage
makes sense. If a distribution is going to do a workaround patch, it
should be to comment out any specific warnings in specific apps that
are truly believed harmless, while filing an upstream bug against said
apps to remove the bogus warning.

But I guess the ability to invoke bug-buddy without crashing might be
a nice approach.

Havoc