Re: Update strategy and timing

On Fri, May 08, 2026 at 01:29:50PM -0700, Mark Millard wrote:
> On 5/8/26 09:37, Renato Botelho wrote:
> > On 08/05/26 12:48, 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?
> > You can follow the stabilization week mark.  More information at:
> > 
> > https://wiki.freebsd.org/StabWeeks
> > 
> 
> 
> Note how this example would work by you [Bob P.] choosing to use
> somewhat older vintages that have been separately tested --based on the
> test results indicating evidence of some stability for your workload.
> That is instead of using the most recent commit that have not had later,
> separate testing.
> 
> The details of the specific testing seem unlikely to be biased to issues
> more specific to armv7 on RPi2 v1.1's or aarch64 on RPi4's, RPi3's, and
> RPi2 v1.2's. I've no clue how the testing would fit with your networking
> context.
> 
> The testing is generally monthly. (2024-Dec was canceled, for example.)
> 
> "* Last week of a month is declared a stabilization week . . . For our
> purposes we will use the week that contains the last Friday of
> the month." Also: "Monday 8:00 GMT a tag is created and published.
> Right now it is published at [the glebius] personal
> https://github.com/glebius/FreeBSD/tags. Note that the tag points at a
> hash in the official repo, so there is no trust involved here."
> 
> More from:
> 
> <https://lists.freebsd.org/archives/freebsd-current/2024-February/005657.html>
> 
> QUOTE of what glebius wrote:
> At the end of the stabilization period be it Friday or earlier I will
> write email to current@ reporting the results:
> 
> - were there any regression identified with the Monday tag
> - what has been accumulated in the stabweek branch
> - known stable point(s) of FreeBSD/main during the period, recommended
> for use
> 
> The free riders who did not participate in the testing are now welcome
> to update their machines to published stable points :) More seriously
> speaking, I actually hope that in some future snapshots.FreeBSD.org will
> start using these points for snapshot generation.
> END QUOTE
> 
> 
> As far as I can tell, use of stable points when fix hashes are involved
> means git branching at the (final) Start hash and then cherry picking
> the fix hashes for the Start hash into that temporary(?) branch: the
> result is not at some commit that is directly on main. (main could have
> had other changes mixed in that were not tested.) So it is biased to
> folks that use git somewhat more like a developer. Sometimes there is a
> "use hash" from main instead of cherry picking.
> 
> The freebsd-current message closing the stabilization week is essential
> to giving context about what to do.
> 
> 
> I do not know how this fits with what you are comfortable doing.
> 

I think it's sensible to make a point of pulling and trying to compile
the source tree at the revision identified as "stable".
 
It's slowly dawning on me that there are (at least) two different
aspects to my question. 

The intended goal was to find out how to avoid attempting to
compile in the middle of a commit process, where some files
are updated but others not, yet. It's unclear over what span
of time a commit, or set of commits amounting to a fix, takes.
If seconds, it's a non-issue. If a day, something worth avoiding
if possible.

Another aspect is avoiding trying to compile sources that
are complete as intended by the developers but which may not
run correctly even if they compile and install. This, more
ambitious goal, seems to be the point of stableweek. 

Broadly speaking, I'd like to avoid build errors if possible so 
that test builds have a chance to crash. Up to now I've guessed
build-time errors are of the first type.

It's my assumption that buildworld is hardware-agnostic: Sources
can be expected to compile without errors regardless of hardware
target. Whether the resulting binaries actually run as intended
on the target hardware is an independent question. Is this notion
incorrect? 

Thanks to all for reading and trying to enlighten me!

bob prohaska