From nobody Tue May 12 13:24:15 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gFHPD3dyjz6cB6p for ; Tue, 12 May 2026 13:24:16 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gFHPD328tz4KWD; Tue, 12 May 2026 13:24:16 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1778592256; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7cVBI+JEsFzUnSuiUo1WQwZbHhlNZyl9Eep7yY7C/t8=; b=PMgSirJz2D0XchZbdEmGYX6g4eYE4XxMob30MH64hDHsIJsufim63t6rzIUwSVGDXkmDlH MufmqE8GZHGSMDqPOwwXAAA5qV6fv0zv8T1n1izXN4gOcEiITmcb2Fy5LhmNqNqVskTGb0 j9QEY3EZtetQbcIMfa/pDCjQ0m1vP6UwEvXXIlqRaaFuuBW1r4flSDbbDQqyFfr4vOEvY4 x19d30YJwbufPZc7P6p5hiLYK2lk+rEgyOiE6gP03lRmPmX5QiTxWx06Upg6uppjQtpLrA NB3WxD8j1nvbkCMp6hjP2hHu//ZyFUXgw3eKNdcnVXd9Bj/Nvo/dzZhZXQTqFg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1778592256; a=rsa-sha256; cv=none; b=GDs7VT60yEVh7CnaYPPia95Xl4PUesxmqBkPMAkXPyMzM8h3Tn4H/MjUWG01CUYu0U8QAN XnPibMCX+zORfjIZzVdyCW/KwZcKOtko/6yEcTNu2jX2VVmiHbJCtbqMwRfQGtQt8fzpXd NXnlMq21HeVdnX1vXhR3tzaW2ItMAlo1Q5tK+oqNWPFQXRteg4pjIzOxGnYlOYzJ4fWMEb 8L4CCNycbN3RuGbv1LDCYBqr+DqX/5Y6RU8CohhpxT/y0gHuQdAehlONZdbkZZsZCmqB/4 Y7qeYOSacUDxiCD+s8AmHx+3iz6XfASy2Z/aGWyFIL40qXSGhB26UwtC6479VQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1778592256; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7cVBI+JEsFzUnSuiUo1WQwZbHhlNZyl9Eep7yY7C/t8=; b=CvcshMChJcW0PtcKtSy9u/rQy+NVGZm0jr4C6/5P2FHVE8qst3A3v/DmfuxmIE5iMVZmiz XE7JT2I46365FHuu1fWuay+GjaUtoGxU8Nj6JtBzpCNyPW7cIO1ZkRwGRaYAiFNYAtjDXH EUQB8EGyN+15q78lzhS5rhq8iBaQNjTVfEgOPJEJ3fGuCDYFvUA25giFEE2yCtGweWwV3g DY3ck1NeGBffJS0IjWZdi3GR6SOSx4dDm7KhH0bJkWZ/GF1j5hG11BxjyWc6xykvaYK3Uv nisvRpwq8AUxn+jDPBLzJ/1RtRjb+bmqqk51zi+C7t+d3FrpDSH+8NHcoq0yZQ== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4gFHPD237mzqX1; Tue, 12 May 2026 13:24:16 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id C705E3C01A0; Tue, 12 May 2026 13:24:15 +0000 (UTC) Date: Tue, 12 May 2026 13:24:15 +0000 From: Brooks Davis To: Warner Losh Cc: Rick Macklem , bob prohaska , FreeBSD Current Subject: Re: Update strategy and timing Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, May 11, 2026 at 07:25:19AM -0600, Warner Losh wrote: > On Mon, May 11, 2026, 7:18???AM Rick Macklem wrote: > > > On Mon, May 11, 2026 at 1:33???AM Brooks Davis wrote: > > > > > > On Fri, May 08, 2026 at 08:48:17AM -0700, bob prohaska wrote: > > > > Is there a preferred strategy to timing updates > > > > for self-hosted FreeBSD systems? > > > > > > > > On the stable branches it's easy; just update when > > > > updates are announced and build/install. Once caught > > > > up, things can be left alone for days at least.. > > > > > > > > With -current there's essentially no pause in the > > > > stream of fresh commits, so git finds a new commit > > > > by the time buildworld finishes. > > > > > > > > Is there some marker or indicator that signals the > > > > -current tree is at least nominally consistent and > > > > buildable? I'm not asking if it'll work, just whenter > > > > it's worth a try. > > > > > > > > For example, my practice has been to run git pull, > > > > then make buildworld. If buildworld succeeds, I'll > > > > try another pull. If nothing new shows up then run > > > > install and reboot. This works with a stable branch, > > > > but with -current there are always fresh commits. > > > > > > > > I've tried looking at the commits to see if they're > > > > relevant to problems I'm seeing, rebuilding if they > > > > are and proceeding with install if they seem unrelated. > > > > > > > > Is this approach at all sound? Is there a better way? > > > > > > I believe the only case where it should be possible to pull and > > > get a broken tree is if someone made a mistake. There are cases > > > where a batch of commits requires two pushes (e.g., a white space > > > commit which must be pushed before .git-blame-ignore-revs can be > > > updated), but I can't think of any cases where something like a > > > __FreeBSD_version bump or regen of syscall tables should be need > > > to be a separate push. > > I do it as a separate push to make MCF'ng easier. > > But I do it literally a minute or two after the commit it applies to. > > I do FreeBSD verson bumps as two commits, one push so i can document the > hash in the commit message. But that's not really needed, except as Rick > points out, MFC is easier. You have both misread what I said. They can and often should be seperate *commits*. There is somewhere between zero and negative value in them seperate *pushes*. (It's usually harmless for __FreeBSD_version bumps and negative for regen of the syscall tables since the tree is generally broken between those commits). We used to have lots of things where had to expose a change to the public before making a follow up change, but we removed the most visible one in 2017 with the removal of "created from" lines in generated syscall files. Now it's mostly internal things or after the fact fixups like RELNOTES. -- Brooks