Re: Update strategy and timing

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.


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