Date: Fri, 6 Jul 2001 13:56:23 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: developers@FreeBSD.org Subject: Re-thinking WARNS?=2 a bit, wrt multiple platforms Message-ID: <p05101000b76ba38bf347@[128.113.24.47]>
next in thread | raw e-mail | index | archive | help
In the freebsd-current mailing list there is a debate raging under
"chgrp broken on alpha systems", which is much larger than the minute
little chgrp command. It also strikes me as something larger than
freebsd-current. Let me continue my trend of being an idiot by
claiming it is a "freebsd developers" issue.
The question is the recent rush to 'WARNS?=2' throughout the tree.
I think the basic intention is the right idea, but the current
strategy has the potential of pitting developers against other
developers, and god knows we don't need anything to encourage that.
The idea is to catch all warnings at compile-time, so it is much
less likely that commits on one platform will introduce problems
on a different platform (i386 vs alpha, and hopefully PPC pretty
soon). The problem is that the list of warnings will CHANGE as
you move from one platform to another. So, the fact that something
compiles without warnings on i386 does NOT mean it will compile
without warnings on Alpha or PPC.
With WARNS=2 set, these warnings turn into fatal errors, and
suddenly "-current is broken on alpha". This just gets people
using Alpha more pissed at people who are not testing on Alpha,
and the situation is bound to get worse with PowerPC or any
other hardware platforms that we try to add.
First apparent suggestion:
Get into a screaming match on freebsd-current every time some
thing breaks. This strikes me as somewhat less than optimal, even
though this seems to be the direction we're heading at the moment.
Second possible suggestion:
Continue to change the source tree the way it has been changed,
but change the distributed /etc/make.conf so it sets WARNS=1 (or
something). I'm not completely aware of what values are valid for
WARNS, but my hope is that WARNS=1 means "Tell me all the warnings,
but don't turn them into fatal errors". The idea here is that
committers could delete that WARNS=1 line in their /etc/make.conf,
at which point they'd get WARNS=2 behavior for all parts of the
tree where WARNS=2 is believed to be safe. People who are "just
tracking -current" will see the warnings go by, but won't have
their current builds broken if some i386-safe commit causes a
minor warning on alpha (or soon, PPC). Those warnings WILL be
fatal errors for people who are doing commits, and thus the people
who CAN do something about it will be encouraged to do something
about it.
Third possible suggestion:
Have an automated "staging area" for incoming commits, and a
commit is not "actually" committed until it builds successfully
on all "current" hardware platforms. This implies some work.
Personally I think this is the only really good solution, except
that I don't want to do the work myself so I've got to con someone
else into doing it.
I'm sure even more brilliant suggestions could be made by someone
smarter than me. My only interest is to (hopefully) get all
developers on in the debate, and get people thinking about the
best way to handle this, while maintaining our good and friendly
working relationship with each other, and still getting freebsd to
work on more hardware platforms.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101000b76ba38bf347>