Re: Update strategy and timing

On Sat, May 09, 2026 at 09:07:47AM -0700, Rick Macklem wrote:
> On Sat, May 9, 2026 at 8:57 AM bob prohaska <fbsd@www.zefox.net> wrote:
> >
> > 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".

Sorry, this passage is a braino. I should have said:
...make a point of pulling the main revision identified in the stableweek email...



> >
> > 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.
> In theory, a commit should be a self contained entity, but in
> practice we all screw up sometimes. (One exception for me
> is bumping __FreeBSD_version, which I always do as a
> separate commit, but usually within minutes of the commit
> it is done for.
> 
That's helpful to know. It sounds like the risk of pulling 
mid-commit is rather small on any given day.

> >
> > 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!
> There is a reason that "main" is not called "stable".
> Stabilization week might help, but it is really a pause in commits
> for new features while stability is checked and doesn't really
> imply the code will be stable at that point. (Maybe more stable
> at the end of it?)
> 
> We (the committers) do try and keep "main" stable, but we
> don't always succeed, which is why "main" gets changes
> first and then they filter down to stable and release branches
> later.

Understood, I chose my words badly in referring to stable above.
I meant "the revision of -main referenced in the stableweek email".

Thanks for writing!

bob prohaska