Date: Mon, 11 May 2026 07:25:19 -0600 From: Warner Losh <imp@bsdimp.com> To: Rick Macklem <rick.macklem@gmail.com> Cc: Brooks Davis <brooks@freebsd.org>, bob prohaska <fbsd@www.zefox.net>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Update strategy and timing Message-ID: <CANCZdfraAoJ1JW_r8CqocHvujh12ZjogZFna2T%2B8V-50Qh8PYA@mail.gmail.com> In-Reply-To: <CAM5tNy7iCsMuyvs9rORBpkkN=H=8uHtrNKPyG2txzSHGp8jgkw@mail.gmail.com> References: <af4FwVaA_3P4yam-@www.zefox.net> <agGUPMPiPP8Twtbo@spindle.one-eyed-alien.net> <CAM5tNy7iCsMuyvs9rORBpkkN=H=8uHtrNKPyG2txzSHGp8jgkw@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Mon, May 11, 2026, 7:18 AM Rick Macklem <rick.macklem@gmail.com> wrote: > 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. > I do FreeBSD verson bumps as two commits, one push so i can document the hash in the commit message. But that's not really needed, except as Rick points out, MFC is easier. 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 > > > > [-- Attachment #2 --] <div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, May 11, 2026, 7:18 AM Rick Macklem <<a href="mailto:rick.macklem@gmail.com">rick.macklem@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, May 11, 2026 at 1:33 AM Brooks Davis <<a href="mailto:brooks@freebsd.org" target="_blank" rel="noreferrer">brooks@freebsd.org</a>> wrote:<br> ><br> > On Fri, May 08, 2026 at 08:48:17AM -0700, bob prohaska wrote:<br> > > Is there a preferred strategy to timing updates<br> > > for self-hosted FreeBSD systems?<br> > ><br> > > On the stable branches it's easy; just update when<br> > > updates are announced and build/install. Once caught<br> > > up, things can be left alone for days at least..<br> > ><br> > > With -current there's essentially no pause in the<br> > > stream of fresh commits, so git finds a new commit<br> > > by the time buildworld finishes.<br> > ><br> > > Is there some marker or indicator that signals the<br> > > -current tree is at least nominally consistent and<br> > > buildable? I'm not asking if it'll work, just whenter<br> > > it's worth a try.<br> > ><br> > > For example, my practice has been to run git pull,<br> > > then make buildworld. If buildworld succeeds, I'll<br> > > try another pull. If nothing new shows up then run<br> > > install and reboot. This works with a stable branch,<br> > > but with -current there are always fresh commits.<br> > ><br> > > I've tried looking at the commits to see if they're<br> > > relevant to problems I'm seeing, rebuilding if they<br> > > are and proceeding with install if they seem unrelated.<br> > ><br> > > Is this approach at all sound? Is there a better way?<br> ><br> > I believe the only case where it should be possible to pull and<br> > get a broken tree is if someone made a mistake. There are cases<br> > where a batch of commits requires two pushes (e.g., a white space<br> > commit which must be pushed before .git-blame-ignore-revs can be<br> > updated), but I can't think of any cases where something like a<br> > __FreeBSD_version bump or regen of syscall tables should be need<br> > to be a separate push.<br> I do it as a separate push to make MCF'ng easier.<br> But I do it literally a minute or two after the commit it applies to.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I do FreeBSD verson bumps as two commits, one push so i can document the hash in the commit message. But that's not really needed, except as Rick points out, MFC is easier.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> rick<br> <br> > As such, pulls "should" all build and I<br> > believe pulls on a single branch are atomic with respect to pushes.<br> > Obviously people make mistakes and that can require cleanup which is<br> > unpredictable.<br> ><br> > One strategy that can work if you don't need the very latest version<br> > is to pick a commit somewhat in the past. For example pick up the<br> > last commit on Friday the following Monday. That lets you check the<br> > mailing lists and follow up commit to have a chance to say "maybe not<br> > that one". I used this on CheriBSD when it was closely tracking FreeBSD<br> > (we still use Friday commits, but are very behind at the moment).<br> ><br> > -- Brooks<br> ><br> <br> </blockquote></div></div></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfraAoJ1JW_r8CqocHvujh12ZjogZFna2T%2B8V-50Qh8PYA>