current@freebsd.org>; Mon, 11 May 2026 06:25:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778505932; cv=none; d=google.com; s=arc-20240605; b=evqc2tW9jkVXEKIHsBckp92TTmgM6RQ6tggyhRTh70uAf+vYLkqzwJvnSTlukN5a5R 6YD/9Zf8wayt2+1lqHXwNs6lermnTLGoMimLS2JQedGVaUIaQ2XPwbuwCKDzVdG42Ltq QEUGFO3b8dTBYo4zW46Sg9UCX1ZJIVSO/HLg+BarCP9M69PiYV2/wwttgMb2Rj96Qvc1 UUhT3M1l0PgOWuUpY3JmeIzDSf05EhqZkWlcnc0XhthzQb7udidbTDedXtoSmRioUkEc Q8PdFNdIcb1GAhBp1XIYMioHBcwF0fgykyfWzWT6X++xvUlKpvK7QpLSpW2+pUlaBe50 sf2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=eNg2JqW30sesVlwWcgs87kfcH4E17sz+G2JOyXOvo8Y=; fh=r0hT/maDDLEcSGNtJteKEPExyZEtB2449bvGXWS/TMo=; b=Sm6Tjyj+4cXLO5RT1ZV+R4CqrPgTUaMA9M8QSgoqhPHLNQSHwNSEx4Q4VxOXdTFBs9 gkKDVv0kw+tCiXSlxHE5JKu8PSV45rF34PGFh119evPtKk9EJAx7AeA4qwVR+llYuRYd 2C9Rby4p5mBgu5AyxmKQAExHcQesFtX0cb52WFOjT1kVNkzDKv8qo+exmlovDqgbCAfi TM2mG7HPx6R/SduFPAU7hATzKV66sHQORcdUWkKYsuIMVjawlkuhlEf9/oKOpm4+ivrE S72uyhHmSgGz+ClrXNTAwUzDyh/fvmHpgvC3Df7ucmuPYWVXUIprSA3g2iF1h/hN1W/l lVOg==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20251104.gappssmtp.com; s=20251104; t=1778505932; x=1779110732; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eNg2JqW30sesVlwWcgs87kfcH4E17sz+G2JOyXOvo8Y=; b=h5B0TPH2/rVq1YKfNH6cJqGE8+eEbghRDfII1rWSc0jZvmWwtpS6O+v2e2RffGxRnH AEjaq+yePvdK0WfpCjmYh1kdatJ+uMl3enaED/3x5b1yssC2LVWa1APoIlzL0f9mNO2I XdU+7rbWieDFsIHHzhQur3z2LDWVakVyGM6+d54VUU013YMZp6ghcRmBebwOxkdYMl9r Zs4P1OdA3VZ5Zizhc31DpxuRdGjncTFUSImxpPVgVOV8mD/VqNiGSh/71OivXws4B+z0 0qnKX5xdpm1O5+GXpYMu6QTIoyNC7BKLDqKhUqAbKi2RcjiiwnadULJYdfxfseAgi8Xq qK3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778505932; x=1779110732; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eNg2JqW30sesVlwWcgs87kfcH4E17sz+G2JOyXOvo8Y=; b=En8IeD2nHipRaWg6RyVGcqVMk7F8XEXCEB0uFwbO2GlGJgupAcPOnihY6C/DKEizdo BkfWW02l1cxz3EERX9NnpzA2URE1vDUzNXPIJtxYBsbRZ4T45up9LpPn8FSdeyiFKKUn R1iFSVVeYT2DMIaIwmC9/NB1bpDmK3Dg2XLjdOJKOhJyNs6pmoJa+j5bpJKxCv4VWXMP wHzhCOw31vyXEgcMS6rNZvQ0ijcWeLpYZYBm3r5/bqWMp019tnSM4pBM9Zm8NoJ/4qTf mqPrSTIl046QE/6neRdcPnyRltWnybw4svekNoI2bNFuQ5zBRt16zM0UqWyOSCzdvByb HymQ== X-Forwarded-Encrypted: i=1; AFNElJ9niEYYsp/k/OuYRgedVzrPFTL832YIcgT3pXXJLriX5kWysY83SIt9yenn6WyR/5UhehEgohVSgwMNIZYoNgA=@freebsd.org X-Gm-Message-State: AOJu0YweR7NCPDq6wiEhiBjT2+rRM7LYHwBfbM4rPIFRzEQAMZxxONIz 43NNDRuewZZQYbUpdITmk2iTp3Kek9GKFL3e5GiFkfkW9He6pgSVsSb1DZR79N34DMPXCqAFPzf Az3z1P1MU6XgRZY0l2LGjLMZFmmMvSLuswDdHENq0ww== X-Gm-Gg: Acq92OGXopo4ysa6CFHQRPo93YefFMwE9jsLQLTH8/61vhblZsNjCO0/ERiasNYXEcG /WN6F8+0vb+/tpc0PRx/4DcHD20Ei8otlbFgG92+mS2lBekskyFgb901+Pa7Lq++3QRLGB9eUm9 Gkh06SZaszyIagArU+jpIsKU4jH08nZLzJZnLdPle9dT4HxzyoPjvHs6jmlYcADvwPMDkVU7y7s BJ8MIWHSznGXF9BevwwnLQlkfIDGu/j8txbw9SuGDk+Zw0cPr6Za59xxoyJ/B51by1ZkpFy9s6Y KcW3lU0m5LTHkHh4+96/uf2Lz0jGrA98Wx39SRZ5pBpCvCw= X-Received: by 2002:a17:90b:2ccd:b0:366:4782:1376 with SMTP id 98e67ed59e1d1-367d49bd409mr10627444a91.21.1778505931996; Mon, 11 May 2026 06:25:31 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 11 May 2026 07:25:19 -0600 X-Gm-Features: AVHnY4IwLiasOwHUp3gKsG6_kSO7KtKV6wFz-vVkYq5GWfv88JSyZ8IPWR0zquU Message-ID: Subject: Re: Update strategy and timing To: Rick Macklem Cc: Brooks Davis , bob prohaska , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000004ecb2006518aae67" X-Spamd-Result: default: False [-2.50 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[google.com:s=arc-20240605:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20251104.gappssmtp.com:s=20251104]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DKIM_TRACE(0.00)[bsdimp-com.20251104.gappssmtp.com:+]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1032:from] X-Spamd-Bar: -- X-Rspamd-Queue-Id: 4gDgTB4xHCz3gks --0000000000004ecb2006518aae67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 11, 2026, 7:18=E2=80=AFAM Rick Macklem = wrote: > On Mon, May 11, 2026 at 1:33=E2=80=AFAM Brooks Davis = 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 FreeBS= D > > (we still use Friday commits, but are very behind at the moment). > > > > -- Brooks > > > > --0000000000004ecb2006518aae67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 11, 2026, 7:18=E2=80= =AFAM Rick Macklem <rick.mackl= em@gmail.com> wrote:
On Mon,= May 11, 2026 at 1:33=E2=80=AFAM 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.=C2=A0 There are cases<= br> > 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 F= reeBSD 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.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> rick

>=C2=A0 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 versi= on
> is to pick a commit somewhat in the past.=C2=A0 For example pick up th= e
> last commit on Friday the following Monday.=C2=A0 That lets you check = the
> mailing lists and follow up commit to have a chance to say "maybe= not
> that one".=C2=A0 I used this on CheriBSD when it was closely trac= king FreeBSD
> (we still use Friday commits, but are very behind at the moment).
>
> -- Brooks
>

--0000000000004ecb2006518aae67--