Re: -Werror

[John Marino <netbsd%marino.st@localhost>]

On 10/13/2012 18:13, Alistair Crooks wrote:
> On Sat, Oct 13, 2012 at 05:40:16PM +0200, John Marino wrote:
> > On 10/13/2012 17:09, Alistair Crooks wrote:
> > > The removal of -Werror from packages is wrong - here's why:
> > >
> > > 1.  The authors put it there in the first place.  They did this
> > > consciously, for a reason - because they want their software to be
> > > warning, as well as error free.  It would be good to respect their
> > > wishes.  Now it may be that they don't have the platform or cpp defs
> > > in place which cause warnings.  But I do know that they want to be
> > > informed about this.
> >
> > This statement makes a LOT of assumptions.
> > 1.  That the authors made an informed decision when they picked it
> > 2.  That leaving -Werror for releasing wasn't an oversight / mistake
> > 3.  That the software is still maintained upstream
>
> Not sure I get the drift of what you're trying to say.  On the one
> hand, you're saying that people just put -Werror into their programs
> because it's a cargo cult thing to do, and yet you have all these
> warnings/errors to fix that they haven't seen and don't know how to
> deal with, and it's way beyond the number of hours in the day, so you
> have to switch off -Werror.

I never said that I didn't know how to deal with them.  The new warnings 
that are causing Werror to trip at develop-time advice, not anywhere 
close to being real errors.  The problem is that they could be numerous. 
 So the choice is to patch several non-problems (because the compiler 
will optimize correctly) or turn off Werror.

Don't forget that others disagree that Werror should be present in 
release software.


> > It's not about "respecting wishes", especially if doing so blocks a
> > pkgsrc from working compilers less than 3 years old.
>
> Can you re-state this one for me, please? I can't parse it.

I think working on new clang and gcc4.6 is more important than the 
concept of "respecting a wish" that might have been made 10 years prior.


> > > 2. Moving to new versions of gcc has had this effect in the past.
> > > We'll see it in the future, too. We've never used a club like -Werror,
> > > there's no need.
> >
> > I think this statement is false.
> > Grepping for BUILDLINK transforms in makefile alone results in 38
> > packages *BEFORE* the recent commits.  Add 3 more for
> > CONFIGURE_ARGS/ENV and several more disabled through patches.
> > Clearly this club has been used, quite often.
>
> If that's the case, why are you switching off -Werror now?  Why wasn't
> it done in the past for those packages?


That question makes no sense.
There are say 50 packages that switch off Werror now.  5 more means now 
there are now 55.  I think you must have misunderstood?


> We've always taken the approach that quality is better than quantity,
> as I mentioned later on.  Why are we now moving to a de-facto "it
> doesn't matter what it does as long as it packages ok" model?


Well, one of my main criticisms of pkgsrc is low quality packages. 
lang/pnet.  The fact krb4 is still in here (apparently to save two 
obsolete chat programs).  Demos from 2006.   Unfinished games (e.g. 
xracer).  Game demos. vlc08.  I don't think pkgsrc is focused on quality 
because it's impossible to get this stuff thrown out.  As I have said at 
least 3 times: There is not even a process that I can see to eliminate 
packages once they are in.  You talk about quality but I don't think 
we're hitting the mark.

Nor do I think -Werror flag affects quality.  The time for it is prior 
to release.


> The case in point is xymon, and the maintainer wasn't asked in advance
> about anything.

The point was that if nobody feels responsible for it, nobody will take 
the lead to keep it updated.  Obviously there are noticeable exceptions, 
but those packages are so prominent they should have a listed maintainer.


> Somehow, I think you're missing the point.  If you can give me an
> anecdote that shows how ignoring warnings is a good thing, that would
> be cool.  Oh, and extra credit given for mentioning NASA in the same
> sentence.


I worked at NASA's Johnson Space Center Mission Control for 4 years. 
Bogus warnings were a daily occurrence for me.  And we switch off the 
alarms if they squawk too much and watch the data (equivalent to 
watching the logs here.)


> > My response is the same as I said to Alek.  If this is truly a
> > pkgsrc command decision, then highlight all circa 50 packages that
> > disable -Werror, mark them broken for all platforms, and then people
> > can fix them one by one.  It makes no sense to pick on 5 more after
> > 50 are already in place.
>
> That's not a response, though, that's avoiding the question. What exactly
> is the point of all this? Is it just to boost the numbers of packages?


Fixing package regressions.
You suggested that packages should be marked broken for DragonFly, at 
least if they were built with gcc4.7 (which obviously ignores any other 
platform using gcc4.7).  However, with your logic, you should have said 
it should be marked broken for all platforms.  Why penalize DragonFly 
for being the first the notice and emit a warning?  Obviously the 
"problem" is invisible to the rest of the platforms, but it still 
exists.  To mark it broken on DragonFly IGNORES and MASKS the now-known 
"problem" on all the other platforms.

There is no way you should have suggested that -- unless you feel, like 
Alek, that this is a DragonFly thing so it's our problem (which also 
points to the general feeling towards non-NetBSD platforms in general).

Or to really answer the question: Some of us don't think the Werror flag 
does all these indispensable things that you and Alek claim it does, and 
the pain of "fixing" it outweighs the loss of removing it.