On 06-Jul-01 Dima Dorfman wrote:
>> In the WARNS= case, another
>> workable method would be to commit the warning fixes but don't commit the
>> actual WARNS= change until the build has been verified on all archs.
> This doesn't work.  The point of WARNS, as I see it anyway, is not to
> scrub the tree so that `make buildworld` produces less warning output.
> The point is that people who are modifying programs are less likely to
> introduce bugs if warnings as treated as errors (presumably, the
> compile outputs good warnings that actually help find bugs).  The
> above (your idea) works when WARNS= is set the first time, but not
> when a program with WARNS set is modified.  This, I think, is the real
> problem; it isn't a problem to test on all arches when you *first* set
> WARNS.  The problem is somebody making a small change to the program
> later.  They may not even know WARNS is set; their code didn't trigger
> warnings on their test box, so they think it's okay.  Furthermore,
> this makes it harder for non-committers to submit changes; at least
> committers have potential access to the other arches (e.g., beast).

Good point.  However, I would argue that we don't need to just lower the
standard and say its ok for warnings to persist.  These things can be fixed to
work on all archs.  One thing that would help is for people to be a little less
uptight and when a bogon pops up on one arch just fix it and go on.  Yelling
and screeching about it doesn't really accomplish anything, and people who are
more familiar with the arch are in a much better position to fix the little
bogon's (size_t instead of int) anyways.

Basically, some people take offense every time the alpha build breaks and spend
more time complaining about it then it would take to just commit the simple fix.
Recently, this trend has started changing somewhat (Matt does commit lots of
quick fixes for simple build breakages nowadays) and I think that just
realising that developers have limited time to spend on this project
(volunteers after all) and being a little more flexible is probably the most
practical solution.  It is current after all.  By the time changes get MFC'd,
they will have surived all the archs and won't break stable.


John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to