From nobody Fri May 8 15:48:17 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 4gBtmd2LsHz6cXkt for ; Fri, 08 May 2026 15:47:45 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 (2048 bits) client-digest SHA256) (Client CN "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gBtmb69jkz3DfH for ; Fri, 08 May 2026 15:47:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 648FmI95053329 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 8 May 2026 08:48:18 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 648FmIrE053328 for freebsd-current@freebsd.org; Fri, 8 May 2026 08:48:18 -0700 (PDT) (envelope-from fbsd) Date: Fri, 8 May 2026 08:48:17 -0700 From: bob prohaska To: freebsd-current@freebsd.org Subject: Update strategy and timing Message-ID: 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 X-Spamd-Result: default: False [-0.88 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; NEURAL_HAM_LONG(-0.95)[-0.947]; NEURAL_HAM_SHORT(-0.84)[-0.843]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; DMARC_NA(0.00)[zefox.net]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4gBtmb69jkz3DfH 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? Thanks for reading! bob prohaska