Re: Update strategy and timing

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

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

rick

>
> bob prohaska
>
>