Re: Update strategy and timing

On Mon, May 11, 2026, 7:18 AM Rick Macklem <rick.macklem@gmail.com> wrote:

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

I do FreeBSD verson bumps as two commits, one push so i can document the
hash in the commit message. But that's not really needed, except as Rick
points out, MFC is easier.


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