Re: Update strategy and timing

On 5/11/26 01:33, Brooks Davis 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.  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.

There are times, like when llvm19 -> llvm21 happened, where some things
can revert and then go forward and the list of commits itself is sizable
--even if they happen over a short time.

It may be that at any place in the middle builds --but that you might
not want the result.

Such points are not frequent but such commits do not normally get prior
notices about an expected time frame. Being able to stick with what
you started with for operation can be important for self-hosted systems.

It can be good to check if you want to use what was actually fetched and
merged (--ff-only) before actually building based on it. One might
notice something like llvm19 -> llvm21 had started. Other forms of using
a somewhat older hash that avoids something like that is an example as well.

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


-- 
===
Mark Millard
marklmi at yahoo.com