From nobody Sat May 9 16:51:20 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 4gCX6t2bYkz6cB7c for ; Sat, 09 May 2026 16:50:46 +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 4gCX6r5k54z3D9R for ; Sat, 09 May 2026 16:50:44 +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 649GpKQm062970 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 May 2026 09:51:21 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 649GpK3c062967; Sat, 9 May 2026 09:51:20 -0700 (PDT) (envelope-from fbsd) Date: Sat, 9 May 2026 09:51:20 -0700 From: bob prohaska To: Rick Macklem Cc: freebsd-current@freebsd.org Subject: Re: Update strategy and timing Message-ID: References: <9ed12219-6e78-4156-b0df-aca91a732127@FreeBSD.org> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Result: default: False [0.45 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; NEURAL_HAM_SHORT(-0.54)[-0.544]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_LONG(0.09)[0.089]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[zefox.net]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4gCX6r5k54z3D9R On Sat, May 09, 2026 at 09:07:47AM -0700, Rick Macklem wrote: > On Sat, May 9, 2026 at 8:57 AM bob prohaska wrote: > > > > On Fri, May 08, 2026 at 01:29:50PM -0700, Mark Millard wrote: > > > On 5/8/26 09:37, Renato Botelho wrote: > > > > On 08/05/26 12:48, 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? > > > > You can follow the stabilization week mark. More information at: > > > > > > > > https://wiki.freebsd.org/StabWeeks > > > > > > > > > > > > > Note how this example would work by you [Bob P.] choosing to use > > > somewhat older vintages that have been separately tested --based on the > > > test results indicating evidence of some stability for your workload. > > > That is instead of using the most recent commit that have not had later, > > > separate testing. > > > > > > The details of the specific testing seem unlikely to be biased to issues > > > more specific to armv7 on RPi2 v1.1's or aarch64 on RPi4's, RPi3's, and > > > RPi2 v1.2's. I've no clue how the testing would fit with your networking > > > context. > > > > > > The testing is generally monthly. (2024-Dec was canceled, for example.) > > > > > > "* Last week of a month is declared a stabilization week . . . For our > > > purposes we will use the week that contains the last Friday of > > > the month." Also: "Monday 8:00 GMT a tag is created and published. > > > Right now it is published at [the glebius] personal > > > https://github.com/glebius/FreeBSD/tags. Note that the tag points at a > > > hash in the official repo, so there is no trust involved here." > > > > > > More from: > > > > > > > > > > > > QUOTE of what glebius wrote: > > > At the end of the stabilization period be it Friday or earlier I will > > > write email to current@ reporting the results: > > > > > > - were there any regression identified with the Monday tag > > > - what has been accumulated in the stabweek branch > > > - known stable point(s) of FreeBSD/main during the period, recommended > > > for use > > > > > > The free riders who did not participate in the testing are now welcome > > > to update their machines to published stable points :) More seriously > > > speaking, I actually hope that in some future snapshots.FreeBSD.org will > > > start using these points for snapshot generation. > > > END QUOTE > > > > > > > > > As far as I can tell, use of stable points when fix hashes are involved > > > means git branching at the (final) Start hash and then cherry picking > > > the fix hashes for the Start hash into that temporary(?) branch: the > > > result is not at some commit that is directly on main. (main could have > > > had other changes mixed in that were not tested.) So it is biased to > > > folks that use git somewhat more like a developer. Sometimes there is a > > > "use hash" from main instead of cherry picking. > > > > > > The freebsd-current message closing the stabilization week is essential > > > to giving context about what to do. > > > > > > > > > I do not know how this fits with what you are comfortable doing. > > > > > > > I think it's sensible to make a point of pulling and trying to compile > > the source tree at the revision identified as "stable". Sorry, this passage is a braino. I should have said: ...make a point of pulling the main revision identified in the stableweek email... > > > > It's slowly dawning on me that there are (at least) two different > > aspects to my question. > > > > The intended goal was to find out how to avoid attempting to > > compile in the middle of a commit process, where some files > > are updated but others not, yet. It's unclear over what span > > of time a commit, or set of commits amounting to a fix, takes. > > If seconds, it's a non-issue. If a day, something worth avoiding > > if possible. > In theory, a commit should be a self contained entity, but in > practice we all screw up sometimes. (One exception for me > is bumping __FreeBSD_version, which I always do as a > separate commit, but usually within minutes of the commit > it is done for. > That's helpful to know. It sounds like the risk of pulling mid-commit is rather small on any given day. > > > > Another aspect is avoiding trying to compile sources that > > are complete as intended by the developers but which may not > > run correctly even if they compile and install. This, more > > ambitious goal, seems to be the point of stableweek. > > > > Broadly speaking, I'd like to avoid build errors if possible so > > that test builds have a chance to crash. Up to now I've guessed > > build-time errors are of the first type. > > > > It's my assumption that buildworld is hardware-agnostic: Sources > > can be expected to compile without errors regardless of hardware > > target. Whether the resulting binaries actually run as intended > > on the target hardware is an independent question. Is this notion > > incorrect? > > > > Thanks to all for reading and trying to enlighten me! > There is a reason that "main" is not called "stable". > Stabilization week might help, but it is really a pause in commits > for new features while stability is checked and doesn't really > imply the code will be stable at that point. (Maybe more stable > at the end of it?) > > We (the committers) do try and keep "main" stable, but we > don't always succeed, which is why "main" gets changes > first and then they filter down to stable and release branches > later. Understood, I chose my words badly in referring to stable above. I meant "the revision of -main referenced in the stableweek email". Thanks for writing! bob prohaska