From owner-freebsd-current@freebsd.org Fri Nov 3 05:22:18 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4E59E6C5B3 for ; Fri, 3 Nov 2017 05:22:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-131.reflexion.net [208.70.210.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6BA17C71D for ; Fri, 3 Nov 2017 05:22:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30236 invoked from network); 3 Nov 2017 05:22:17 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 3 Nov 2017 05:22:17 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 03 Nov 2017 01:22:17 -0400 (EDT) Received: (qmail 25389 invoked from network); 3 Nov 2017 05:22:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Nov 2017 05:22:16 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id ECA05EC8FCC; Thu, 2 Nov 2017 22:22:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Head build unsafe for /etc today From: Mark Millard In-Reply-To: <20171103035010.GA89291@troutmask.apl.washington.edu> Date: Thu, 2 Nov 2017 22:22:15 -0700 Cc: Bryan Drewery , freebsd-hackers , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <9BB08DDC-75A9-4115-936A-81E7319B166C@dsl-only.net> References: <3045EEBF-09E6-4209-B54F-2F95394DBA82@FreeBSD.org> <20171103014907.GA88522@troutmask.apl.washington.edu> <68BECDA4-C182-436E-854C-C3B19ABB4373@FreeBSD.org> <20171103022327.GA88659@troutmask.apl.washington.edu> <998FF503-D4B0-4AD5-AD55-98680E4D66CA@FreeBSD.org> <20171103035010.GA89291@troutmask.apl.washington.edu> To: sgk@troutmask.apl.washington.edu X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 05:22:19 -0000 On 2017-Nov-2, at 8:50 PM, Steve Kargl = wrote: > On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote: >>=20 >> Are you accusing me of lying? >>=20 >=20 > Nope. I'm stating the obvious. If you are using > META_MODE and you do "make buildwould" that is=20 > equivalent to "make -DNO_CLEAN buildworld", which > means you did not rebuild the *world*.=20 Also from a prior message of this sequence: > If your first step isn't 'cd /usr/obj ; rm -rf *' or equivalent > in whatever jail you use, then you're not properly testing=20 > your changes to the build infrastructure. With or without META_MODE, a rm -fr /usr/obj/* before the build attempt forces a rebuild as far as I know. It may be more that cleaning was effectively not tested then rebuilding was not tested. But always doing rm -fr /usr/obj/* first establishes a very limited context for testing cleaning. WITH_META_MODE and WITHOUT_META_MODE still might not be strictly equivalent after the rm -fr /usr/obj/* for some other properties in such an "empty" context. So testing those combinations makes sense but would be insufficient. > When I see a commit message of the form (and I've > haven't seen one like this in 25+ years of using > FreeBSD (aka 386BSD+patchkit)) >=20 > Author: bdrewery > Date: Thu Nov 2 22:23:00 2017 > New Revision: 325347 > URL: https://svnweb.freebsd.org/changeset/base/325347 >=20 > Log: > Something is very wrong >=20 > Modified: > head/Makefile >=20 > Modified: head/Makefile > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346) > +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347) > @@ -1,3 +1,4 @@ > +.error Bad revision, please wait for a fix in head >=20 > It suggests that whomever did the commit did not properly test > the patch. The use of META_MODE (or any other shortcut) when > testing simply isn't proper testing. I think I understand the intended point but the actual wording for "the use of . . ." and "[i]f your first step isn't . . ." is wrong from what I can tell. The testing of WITH_META_MODE is a proper form of test but is not a sufficient category of test overall. But omitting all tests of WITH_META_MODE would be poor procedure in my view. Some testing needs to be done without rm -fr /usr/obj/* after a prior build as well. Some testing of WITH_META_MODE after a prior build needs to be done. Some testing of WITHOUT_META_MODE after a prior build needs to be done. And so on. At least that would be my view. Any and all mistakes checked-in are examples of insufficient testing --but always doing sufficient testing requires establishing a much simpler, more limited, context. To my knowledge FreeBSD is not trying to scale back like that. (It is not under the direction of an Edsger W. Dijkstra.) I do not know if something might be able to be done to make such a specific type of "clean test" mistake less likely to happen again. Could a test context be established where attempts to delete outside the build tree would be rejected, with notifications of the attempts? Could running such a test be automatic (part of something that is run systematically) and fast enough to not want to skip it? (Just being illustrative. The details involved are well outside my background knowledge. There may be nothing easy or reasonable.) =3D=3D=3D Mark Millard markmi at dsl-only.net