From nobody Mon May 11 08:33:00 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 4gDXzd07X6z6cNxN for ; Mon, 11 May 2026 08:33:01 +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 4gDXzc5YBMz4MNc; Mon, 11 May 2026 08:33:00 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1778488380; 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=FKAMlxCiUKwRs97BtZa6iu5Vmz3f0NfuX9QSxdd1vqQ=; b=Dfp/5muChhtXgTHt1CbmK5vl9nb3Sb90Blu+MtWtTVGHMyPplX8mcoFECc36vo3LG6XV5m 1yB5k+LIItVxWHxpGlS/TdY5qLNwQSVqlHqjLXsIYkRuz5zEB362jl17gR5FxxGNo5D3y5 Xc6lsgJqGD0sdt0H07PiHUT4wE8LhduOdKMCT5BGVnc/tob5f3MUHOusby6yOj57SuGiAu A3nHiHR95liGa4FmIf9DwMqmWOkKTmC9E+xbFNadcaZkpTAMaoKnmfN5JDimWZ9MhcL8Vi 2Ifn5/ufVGJnp0bHGSM59Cqmd09Ru4yKuhlHDfRNFCyZAtizOPToCxaDJhQacw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1778488380; a=rsa-sha256; cv=none; b=CL4yas7jc7ezKWMguAyOyyoT0e4gIMbvB14XABxjXuJaqaxDVb4psnzFbVmMb8eORH+xm3 1snfnPA54m7Z5O4H457sCKQSEM54itzjDtTg6q9HsFtPGoe11qtyQeij2Z1Nv0YWL9VU9F aaKHHup+Pth6hyQFQ/A6quXQsjuwNSM2Oiwn2Ws+qMxbnVy/CJiJzqgid564ec/EeQLk9e pJcUDOA6/1Zas1RYB5IHlyMO49iq+qH1peTmsp5AybJlJ3AS/LIeSL1C5YKLjCxElVNc5g 76Bq/ygKhgh43LX/L/rh6K5dNRj6yXDd0eN948aPh73q3z6aRFjxuyLO7QnjOQ== 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=1778488380; 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=FKAMlxCiUKwRs97BtZa6iu5Vmz3f0NfuX9QSxdd1vqQ=; b=gYmHUQqNQ/7ZqVFaPNgKYun4bM70JTLAyFqthyJBXDGta1pOAogL4KAHzXF6au9wyCOJ7k W8sJtkZlaZV78gYgpzuDQVDMYz4m0REIXZGBXJSRY9aGkvKbU3oIshFnmsXWBkbh9YqW3z 445HMaoBh861Alhrm0svwatn5A1yh123EJ2bJmJhaVfwbqYol+/WxaWNUpJ1aFEuuMBt6Z 3pEbJfVbpz7uDM51uSNCKgkoJO49gitD45U1iFTT7iLaVT3ny0lZ3A730dQrOnPk9lbdgZ CNsA2hJDSrqgWKrJ1W5ckx1YDkACrT75e3ZswoLLW4TiwMy1Qw8mCcThiIaD5A== 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 4gDXzc4kTJz1Pcy; Mon, 11 May 2026 08:33:00 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 25F273C01A0; Mon, 11 May 2026 08:33:00 +0000 (UTC) Date: Mon, 11 May 2026 08:33:00 +0000 From: Brooks Davis To: bob prohaska Cc: freebsd-current@freebsd.org 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 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. As such, pulls "should" all build and I believe pulls on a single branch are atomic with respect to pushes. Obviously people make mistakes and that can require cleanup which is unpredictable. One strategy that can work if you don't need the very latest version is to pick a commit somewhat in the past. For example pick up the last commit on Friday the following Monday. That lets you check the mailing lists and follow up commit to have a chance to say "maybe not that one". I used this on CheriBSD when it was closely tracking FreeBSD (we still use Friday commits, but are very behind at the moment). -- Brooks