Re: Update strategy and timing

On Mon, May 11, 2026 at 07:25:19AM -0600, Warner Losh wrote:
> 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.

You have both misread what I said.  They can and often should be
seperate *commits*.  There is somewhere between zero and negative value
in them seperate *pushes*.  (It's usually harmless for __FreeBSD_version
bumps and negative for regen of the syscall tables since the tree is
generally broken between those commits).

We used to have lots of things where had to expose a change to the
public before making a follow up change, but we removed the most visible
one in 2017 with the removal of "created from" lines in generated
syscall files.  Now it's mostly internal things or after the fact fixups
like RELNOTES.

-- Brooks