Re: Update strategy and timing

On Mon, May 11, 2026 at 1:33 AM Brooks Davis <brooks@freebsd.org> 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.

rick

>  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
>