Re: Change to FreeBSD release scheduling etc.

On Mon, 15 Jul 2024 16:58:16 -0700
Colin Percival <cperciva@freebsd.org> wrote:

> On 7/15/24 15:59, Warner Losh wrote:
> > On Mon, Jul 15, 2024 at 4:20 PM Colin Percival <cperciva@freebsd.org 
> > <mailto:cperciva@freebsd.org>> wrote:
> > 
> >     On 7/15/24 15:05, Warner Losh wrote:
> >      > 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.
> 
> New functions in LinuxKPI is the case I was thinking of.  It doesn't prevent
> kernel modules compiled for earlier releases working with the newer release,
> but because we build kernel modules on a per-stable-branch basis we have to
> wait until the previous release EoLs.

It would be the one most frequently happening recently.

For environments where updating/upgrading via freebsd-update are not
provided (like main and stable branches), admins are basically requited
to update/upgrade base via src. These cases, they can put kmod ports
into PORTS_MODULES variable in /etc/src.conf, thus basically no problem.

Unfortunately, this WAS not enough true for drm-*-kmod ports as they
often took behind and "broken time window" persisted until they catch
up with base. But fortunately, at least for stable/14, it seems to be
significantly stabilized thanks to the tireless efforts of graphics
team.

So, remaining problem would be the screams/sighs on forums.freebsd.org
when any binary kernel updates (patch releases) are provided via
freebsd-update, and/or when someone attempted to upgrade their base to
non-*.0 releases on different stable branch (i.e., upgrade from 13.2 to
14.1) while previous point release is still not EOL'ed.

As admins should be strongly encouraged to run latest patch (-p*)
release of the point release they are using, kmod pkgs should be
provided for latest patch release only on single point releases.
(Means, when 14.0 is at 14.0-p3 and 14.1 is at 14.1-p1, and 14.0 is not
yet EOL'ed, kmod pkgs for 14.0-p3 and 14.1-p1 should be provided.)

> 
> -- 
> Colin Percival
> FreeBSD Release Engineering Lead & EC2 platform maintainer
> Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>