From nobody Mon May 11 18:49:49 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gDpgS3NyDz6dRCF for ; Mon, 11 May 2026 18:49:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gDpgR5WTXz3Swt for ; Mon, 11 May 2026 18:49:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778525391; bh=vJIoEUNjzF6y4U2K/QBtUZPd5lEXEugWSpG+wUoIL4Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=afOhPqXYgbgvzJAg7tPoUSPnc3pjJibyh5gmITBAV1ISSU2HOgrR+ZoogcUw0UBJ5/WeggjwmvCQF/DNTn6G2k17qPDT2eBmN3G2QVSpHUXBNLQ46dMmYYmL+GXdjDpZM55T+ADb2H9sAbTHot0RDzC2dpCHln4Yr3DvKON3YQLSWEhL/gEgGSHXkMpHcJgFzFmvikY87/doy0Dz7IH2xRWS8GpBmqaUfAxsETE/748ImUFrv70rSaq6AGpBPLY6efENEVFy71hB6JHgzToRmeGWzezPeAB/ZLn5UvhqsB+99M/cgj/xZb1ZHsJVxKjW72zvyeRCsCpM9WVr09DcJw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1778525391; bh=OibZ7vHYZZp51+z/yRX61iZJ8fnE9vG1CHiEiX0oMM6=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=QR05tVxDvzJQCbyKPgSIWZ5LB2reXu9T7KdomWVG1WINRrXzDxOoXbmJ5WbBkifvUsalkOXD61oLS2ZQwqG8cKY3UHI27f9O+inZD2Fuq8Ror+BtYboYXUw7ghsEcgpJgVcnEabmIt2JTsl2+2jU+d6EdtMk8e53IAqu1WiahaX4F8mmE1CrpKQZguXvumO59djMN9fYMa++HikSuBBIXNHJsq4JfsT9QiACjIXhZwC5Hcj3bT5fSvd85bg12ysmIS7aX3FiIyMahlGjWxdarRTbLVqwt3io0qv4kXI8LIjPZXyxY2dZXsMftIyTabiP3MFCIxcHyKhklLwfI/ZduQ== X-YMail-OSG: EQLCnPUVM1nhlsjd4E9da8DsboiYLGzgXAuBazncv9l8UVW3PbdbkRhYotdYpor jPsxYXXyCooUyqPrzCOLX.rjPVbQtUSwYwqfb2OTiJPNJLsWsJpK0v9ti26yEDL_1CQu0hHAmHFP Yv0h4m9ynBndVAwWmhOUmMsaVOf.xttpiiBKwW0ehPbfHtwYdxlxwGlzRe8mPYTpjj8xCnlIAhRO 9Vp2SAvmGm5CCglR4THVsRisLPEnjrjW_zx1m6WMy8JM76ClFIVcptOVQNNZsuJTOqPkzjRiv1ma t1ktxyeR7_PZjEaiC7dPXlxETOQs7If7peGxXpocpZ0ndH6lDCKRfgQqZY5U7NJFAjg4piLTg7gV 6_VJHfVf6JQJxVcPrWX9Rlss.qc_bJaIVF.tgcvWC4uAGowc9HfaQVcRkk_3i2JDPx.KgptnZuXi 5FOlfVGvIzGH3syruESjd6L.4tz5WjCqd9htrRoNOzciTI6QDxg_wcnWjZQ4Pe8._fCewCeedc0o KsjtW2Trv_dnkBNjP9RTC726g81ZyLyVC6JZiBDpBfYYXNurjgq5S8Rssaaqyq7zJq9pH6eGXnZc dHa91tJDS7b8yLPDGt9LDQ7XjIWeDzONr3SlQWR_8fUcZH..f4qCZBudbzrajWPFEetIvoGnVqTt Ws51H8GDhtg1lbgIaQFLpuh8_Oe8x_NUKHo.OP2UnKoaI7OQRQbNnwiUu6RSQG8bgoferjztPHnK xVK.LJfRRnRCif2Hzy2R0L7wXrCzGNSMMftiP2QOijfddGXTvuAi6zvwNfVG5xJkGrMV.luXjR2r MpccChaIlgu8loJorK0xB42LdHnW_ILrovEp5elpd3JGIs0HTdk6cnHBoxcu0QwHNPI2sWz0cBSh 1ggov6FbpE9p8q16k47vABaUDQnU035opSerzSXrIfS1JKV6Kj6v4Xuuzu02ijKVHkV6HyiC_C_p 68d5roj.fdHPJfw7hXRv3aKV4hyod6qCTIkwrdziLAcicQ.Ao5y2kKRNZU3HPGgUv1drfF6.Xt0k Ho.8hv7FLWPyXNw59pmmOC4h5RTx3TQEQZvoVmBLvtKl1GoI9gqWHy4tUQgEzutSm0raydM5kFN8 _09wpb0rHYoKvmMXjl4_R2QXfncc0QkBL.e6PcKSGUzHUWXFCFbW0ql6K7vLSi0WRsgZnZ.Az926 ul5r3hgTOxXajA4AGcZl4ACi16_y.t05na7FfML3bdFAtTmGOlkBVie0m_CcOUzBz4SxsoafolUx _Joxn7j8emDkTtr6sEECVzmQnSxqLwnqQ_F6K0.axu.jkOxqv.2zEu5Rg475kvKPBbO45nIJRJQp X.BY70E1EoJY1Ij9_wa6BAFpcn_ZUmft7O8BoiLroolnweIA8hZ5ctoYbODAfY5.3ZFSQjjBA6qB Z7G.B8VlV0Wy_a6iOMzZExv0pD7XRfXR388hTjjBENzogc6dg1MXZZTVYRt7l1tbrk0gJ3zzYKPJ MCXc3TrwRHW9X33BeM7dIP8vcK2J8P8nubPC9o10yYMJlWeZrtmZmsXLIMIEpEG4N3dJlToSVOlq hjLmuLTrjnwVmyf9JCxToQEv7fXfx1xCjdzx78T2udzcaeUNcL0xgBgyT0WRTwPCeCjtthTHPXHz hCa.dUZfPluDIyJY3AjEYSo34NzbIdxIenVg2C27.YQaqinDI2Kh7NqetR9dhv_OaLj1_k8BOJqC Y0gIkvxRjG1yLIfLc12bDkqlHHfARWTJAK.2Srcm_EWnipnz2vlpciiuAUa_42LcR3Ow0De8GjgE geENbYK28_uPWHr1bT_c2YxF7sh0t8xx6TpoKDJzm.bDCxNb5YgVawvmbebzxr8q.NHzMmXp8YVy jIgSKQCrOKZYXvoepOq8nR4AK9VvDXR9kU76rYTF5fcY54TbHT13KFyMmmda3feI1hYiqyDpTMgh 0ObwLeJs.KoodxjtoBX9L8NKenwwpE7S1rXZTmppKtiH1bbgiFLIOvaZpQbX1VevdymQylQd7Yt5 q3A91Y7ApYkXh5vX7h_6A.igBUsUxdtudS9QFmblF2y0ng26ZpTkk4CVCTzylTtYFxCzuQSiF5dd XLLaJabEphiLwIyiiLvjXnsNeNOKBYzdbi4l3LVmULqit8L2kNgiDtGIeXDUwWQbSgbsUGcq4Mz_ F3Zih7Fn_WgOXIdJTCZtUFdMR6n1PNhbKQzOd9VqrRA5qRQqM3Bnr5lpToeigNnGddP0i2XS9hdI b2ovbOuoXvRoI.LzI9n6.z1Je8XFjZPJIz3S1m.mLCLF1G9p6_pxSIq_N6rcajQWXGPomcBqbSXm HMP9Vcvq5RjDG3SsBxVVvEUgiNzisMeLc5Vndy4j1bb6Tciu27fHgNhyf X-Sonic-MF: X-Sonic-ID: bb918678-00a8-4cae-a8e4-0a0263a736fe Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 11 May 2026 18:49:51 +0000 Received: by hermes--production-gq1-7bb7df5c46-hjhbv (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c6a898fd2c1ca858d5aacc8ea6628f67; Mon, 11 May 2026 18:49:50 +0000 (UTC) Message-ID: <45ed6c2b-4cda-465e-8fa1-b2533147e945@yahoo.com> Date: Mon, 11 May 2026 11:49:49 -0700 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 User-Agent: Mozilla Thunderbird Subject: Re: Update strategy and timing To: Brooks Davis , bob prohaska Cc: freebsd-current@freebsd.org References: Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25725 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4gDpgR5WTXz3Swt X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 5/11/26 01:33, 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. 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. There are times, like when llvm19 -> llvm21 happened, where some things can revert and then go forward and the list of commits itself is sizable --even if they happen over a short time. It may be that at any place in the middle builds --but that you might not want the result. Such points are not frequent but such commits do not normally get prior notices about an expected time frame. Being able to stick with what you started with for operation can be important for self-hosted systems. It can be good to check if you want to use what was actually fetched and merged (--ff-only) before actually building based on it. One might notice something like llvm19 -> llvm21 had started. Other forms of using a somewhat older hash that avoids something like that is an example as well. > > 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 > > -- === Mark Millard marklmi at yahoo.com