From owner-freebsd-current Thu Jul 5 18:54:49 2001 Delivered-To: freebsd-current@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id CD42A37B406; Thu, 5 Jul 2001 18:54:45 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 5B7203E28; Thu, 5 Jul 2001 18:54:45 -0700 (PDT) To: John Baldwin Cc: Jordan Hubbard , freebsd-current@FreeBSD.ORG, Jim.Pirzyk@disney.com, des@ofug.org, obrien@NUXI.com, mjacob@feral.com, kris@obsecurity.org Subject: Re: chgrp broken on alpha systems In-Reply-To: ; from jhb@FreeBSD.org on "Thu, 05 Jul 2001 18:04:29 -0700 (PDT)" Date: Thu, 05 Jul 2001 18:54:45 -0700 From: Dima Dorfman Message-Id: <20010706015445.5B7203E28@bazooka.unixfreak.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin writes: > > On 06-Jul-01 Jordan Hubbard wrote: > > Well, unless implicit pointer-to-int conversions have suddenly become > > fatal, it blew up on something that just got fixed (I went to commit > > the fix and found that someone else had already done so in the last 12 > > hours). The world build has been restarted and is running again. > > 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? > 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). 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). Thoughts? Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message