Re: Change to FreeBSD release scheduling etc.

From: Warner Losh <imp_at_bsdimp.com>
Date: Mon, 15 Jul 2024 22:59:49 UTC
On Mon, Jul 15, 2024 at 4:20 PM Colin Percival <cperciva@freebsd.org> wrote:

> On 7/15/24 15:05, Warner Losh wrote:
> > On Mon, Jul 15, 2024 at 3:57 PM Colin Percival <cperciva@freebsd.org
> > <mailto:cperciva@freebsd.org>> wrote:
> >     Flavouring kernel module ports for each minor release -- possibly
> building in
> >     in an oldest-supported-release jail but with the relevant
> /usr/src/sys tree --
> >     might work well?  But that's a question for portmgr; I don't know
> enough about
> >     how package building works to know how feasible this would be.
> >
> > People have talked about "stacking" repos to accomplish this. We'd build
> per-minor
> > release images for .ko's. I'm not sure what the sticking points are for
> doing
> > this,
> > though.
>
> That would be good, but drm-14.1-61-kmod-6.1.69_2 (aka have multiple
> versions
> of ports and require users to kmod packages to pick the right now) would be
> better than what we have now.
>

Indeed, but the upgrade path sucks for that. And all the infrastructure is
in place
to start doing the per-minor-release repos to augment the per major release
ones.
I'm unsure what the holdup is, though. I've cc'd baptiste who may know.

It's the least bad solution, though. It solves the problem for release
points, but
not for people on stable between releases (except accidentally sometimes
when
things haven't yet diverged), nor for current (since it's nothing but
breakage of KBIs :).
For that problem, only a build-from-source-for-each-new-kernel-build can
work.


> > Ideally, we'd keep the same KBI per major release, but that ideal has
> fallen
> > short.
>
> Having a stable KBI only solves half of the problem.  With DRM especially
> it's
> useful for people running the latest minor release to use kmods which make
> use
> of functionality which was added in the latest release before the previous
> release is EoLed.
>

Functionality added where? I'm not following the point you're making
here... But since
KBI stability isn't going to happen (at least given our past track record
and a lack of
tools to enforce it), it may be just an academic exercise.

Warner