Date: Thu, 2 Nov 2017 22:22:15 -0700 From: Mark Millard <markmi@dsl-only.net> To: sgk@troutmask.apl.washington.edu Cc: Bryan Drewery <bdrewery@FreeBSD.org>, freebsd-hackers <freebsd-hackers@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Head build unsafe for /etc today Message-ID: <9BB08DDC-75A9-4115-936A-81E7319B166C@dsl-only.net> In-Reply-To: <20171103035010.GA89291@troutmask.apl.washington.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Nov-2, at 8:50 PM, Steve Kargl = <sgk@troutmask.apl.washington.edu> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9BB08DDC-75A9-4115-936A-81E7319B166C>