Re: Head build unsafe for /etc today

On Thu, Nov 2, 2017 at 9:50 PM, Steve Kargl <
sgk_at_troutmask.apl.washington.edu> wrote:

> On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote:
> >
> > Are you accusing me of lying?
> >
>
> Nope.  I'm stating the obvious.  If you are using
> META_MODE and you do "make buildwould" that is
> equivalent to "make -DNO_CLEAN buildworld", which
> means you did not rebuild the *world*.
>
> 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))
>
> Author: bdrewery
> Date: Thu Nov  2 22:23:00 2017
> New Revision: 325347
> URL: https://svnweb.freebsd.org/changeset/base/325347
>
> Log:
>   Something is very wrong
>
> Modified:
>   head/Makefile
>
> Modified: head/Makefile
> ============================================================
> ==================
> --- head/Makefile       Thu Nov  2 21:58:18 2017        (r325346)
> +++ head/Makefile       Thu Nov  2 22:23:00 2017        (r325347)
> _at__at_ -1,3 +1,4 _at__at_
> +.error Bad revision, please wait for a fix in head
>
> 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.


FreeBSD has grown too big to test every possible thing before you commit.
Lord knows the number of make universes I've done is maybe 1/100th the
number of commits (or less) I've made. We all take short cuts, or fail to
exhaustively test every single possible thing, or have some environmental
contamination that normally isn't a problem but masks an issue, or forget
to add a file / directory, or a hundred other things that can and do go
wrong. It happens. It will happen again. I just hope to never again be the
last person to break the tree before BSDcan again, but I live in fear that
I'll miss something because I know I'm human.

Personally, I think that this commit was the responsible thing to do: He'd
just committed several changes. It wasn't clear which one needed to be
backed out. While he tracked down the root cause, he put in counter
measures to make sure that nobody else got bitten by the bug he himself
encountered when he was further testing the system. He then resolved it by
fixing the root cause, but I know that had he not been able to do so, he'd
have backed things out.

Part of being in this project is recognizing that and allowing the
occasional oops to happen w/o making an unduly large case out of it...

Warner

Warner