Re: Update strategy and timing

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