Skip site navigation (1)Skip section navigation (2)
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>