Date: Mon, 11 May 2026 06:17:28 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Brooks Davis <brooks@freebsd.org> Cc: bob prohaska <fbsd@www.zefox.net>, freebsd-current@freebsd.org Subject: Re: Update strategy and timing Message-ID: <CAM5tNy7iCsMuyvs9rORBpkkN=H=8uHtrNKPyG2txzSHGp8jgkw@mail.gmail.com> In-Reply-To: <agGUPMPiPP8Twtbo@spindle.one-eyed-alien.net> References: <af4FwVaA_3P4yam-@www.zefox.net> <agGUPMPiPP8Twtbo@spindle.one-eyed-alien.net>
index | next in thread | previous in thread | raw e-mail
On Mon, May 11, 2026 at 1:33 AM Brooks Davis <brooks@freebsd.org> 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. I do it as a separate push to make MCF'ng easier. But I do it literally a minute or two after the commit it applies to. rick > 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. > > 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 >home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy7iCsMuyvs9rORBpkkN=H=8uHtrNKPyG2txzSHGp8jgkw>