On Thu, Jul 05, 2001 at 06:54:45PM -0700, Dima Dorfman wrote:
> > Matt Jacob usually steps in and fixes breakages on the alpha. At the minimum,
> > people should be either testing the build on all archs, or asking for someone
> > else to review the patch on archs they don't have available (this last is a
> > more feasible means as we add more and more archs, we can't expect everyone to
> > own a x86, sparc64, ppc, alpha, and ia64).
> No, but I think it's reasonable to expect that we can get some
> test/build boxes for these arches like we have beast for the Alpha.
> I'm curious how NetBSD does this. We got the WARNS stuff from them,
> and they have a lot more arches than we plan on in the foreseeable
> future. Kris?
I don't know how NetBSD deal with it.
> I guess what I'm saying is that we might want to rethink how we use
> WARNS. It'd be nice if the tree would compile warning-free on all
> arches imaginable, but this simply isn't going to happen. Perhaps it
> makes sense to set NO_WERROR by default in a buildworld so that
> causing a warning on some arch isn't considered as bad as breaking
> world (this is less important on -current than it is on -stable).
> Kris already said that NO_WERROR would be the default in -stable, but
> it may even makes sense in -current; those developers that have a few
> spare minutes can unset it when they build world, and fix the warnings
> (or errors, now) as they encounter them. This has the advantage of
> making less people angry, and keeping the benifit of WARNS (i.e.,
> finding bugs before they turn into a multitude of PRs).
My thought has always been that if it becomes too troublesome to
prevent people introducing fatal warnings on some architectures, we
can enable NO_WERROR for that arch. This will also probably be needed
during the porting phase to new architectures which may produce
different kinds of gcc warnings.
I guess it's up to the alpha developers to decide if the rate of
warnings being introduced is annoying enough to warrant NO_WERROR on
their platform, or if it's better to just fix the (usually trivial)
warnings as they come up, so the code stays clean and portable and
doesn't get left behind.