On Mon, 13 Jul 2026, Olivier Certner wrote:
Hi,
If the code is going to exist in the repo then we need to do better at actually
making sure it builds, and so I might make the controversial suggestion that,
so long as i386 kernel sources exist in main and are supported in at least one
stable branch, we should have at least one kernel config that’s part of the
default universe build, so we actually test the code rather than finding out
it’s broken when a user reports it or it gets MFCed. This state of affairs
doesn’t save effort, it just defers it, and if anything makes it worse because
people have to diagnose the error, rather than it just be fixed from the start
by the original author.
As a person who fixed several i386 compilation errors by others, I completely
agree. This is common sense, and I don't see how that could be controversial.
Some people are loosing time because of this, and overall it makes the process
more inefficient than it could be. If for some reason re-integrating it in
universe builds is not sustainable, then that simply means it's time to let go
of i386.
According to https://www.freebsd.org/platforms/ i386 kernels are only supported
on 14.x.
Most of the commits seem to not even be flagged for MFC to stable/15 from what
a quickl glance showed.
CI is still building i386 for stable/14. See https://ci.freebsd.org/tinderbox/
. That means we will be notified if anything breaks there.
With 14.5 happening in September 2026 I assume we should only see important bug
fixes for 14.x and no new features or mass MFCs anymore.
If one individual commit breaks i386 kernels in stable/14 that may even be
easily fixable with a direct commit there.
So why don't we just stop wasting more time on i386 kernel builds in main or
stable/15 and leave to it those people who do want to MFC to stable/14 still to
be careful (or deal with the fallout)?
/bz
--
Bjoern A. Zeeb r15:7
