From nobody Mon Jul 15 22:05:44 2024 X-Original-To: freebsd-stable@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 4WNGVY1d1Fz5QHDm for ; Mon, 15 Jul 2024 22:05:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WNGVX4rJJz4vs9 for ; Mon, 15 Jul 2024 22:05:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-2c9a8313984so3921928a91.2 for ; Mon, 15 Jul 2024 15:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1721081155; x=1721685955; 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=drsfa2vT25wH/nyaDqqlK7tC1dFeWGTbAunMn8rkuu4=; b=Ku2g/YsCocdF29ZU2Q0wDCU8cDA5Dn/zWhwq0WubffD2UtWcDb6mx6uhjtBMPM2qco eMFmKCrP2dIhYJeRZpr4h8xbepUhYSm/kN9yGRYPoX6eMDnqTntGs931gNnX21DSo2iW q0OuI5xoTd+SY34Quptt0fZsm3FSOPGAReIvMojrxzbGAb/eyDoFzcyk3yABcKv9aRuj 0oHm1qIKjRcJTq4NUjNaWFytrJEZ49PF5DQjCesafRK1ulpaOPQQqNXEWq2tHfU0rqgl 33e0jFwxPXKFJg4UsDOWoXbnV6llwdDme4TlcqG3wS5+hiNWt9svtoVHylOLjHkKmr7e gENA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721081155; x=1721685955; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=drsfa2vT25wH/nyaDqqlK7tC1dFeWGTbAunMn8rkuu4=; b=QLAThJsn91nbpT160EvM9lafW37/GZ9BivizjgPSM2mWSnilVWa1f9bt+2C7txEsZR NZLZmFT5ym2ma3epqtMTdqlBBZukfvk6KyRs1vAOH4bkIYAJffoxVdwjRmTHOJNEtce8 JscWmuwNz1Gumbu1ZpNl0JiSfUX5XfI67yjnDBko4a4smHh5lhjEn1VhVsHAhwgwbDjR cI9hxqDdWmzBtweURJMP4bRcNBCzG4NjCWDRObWJ6NnDzj51CWGe8y2ecMhQ0kkJaxEy o0Z5F2F/Bc2Fwi8DT/MK4RzDMXrS7Nv9ymayIfFbcr97wOUeCamnXqzT1cVMq9AmLn9u q++A== X-Forwarded-Encrypted: i=1; AJvYcCW1LYLGarbGrCqB5suDQ8lLVb6I/SjFR0D3Nc02lh5a9mhvV36xZDsdwWJ5bEwrJJwgIdMqHU/vsL/R7XyI4Jw2OvfDFJLiLZVpqQ== X-Gm-Message-State: AOJu0YweUsIQoHlpe2WJElhN2vZ5dFgB37JYj9/dm/nNlVhkcKpxPImp qKXKjDL9+LAAsHEgSQfg2gyRXFG4au3ZXwIxxdgBQJ2t4xEV/GAYfa4pbnK4TV4pY2M97U/9uAN 8RzKqeHM8Bx+78brS7DCGgS8vpkrFUNBsuU99nO8M9ymI4pe0cik= X-Google-Smtp-Source: AGHT+IEN7J7c9Lxg30gModnMrahyMnbg1mAOuJDQBmfGVCRArWLKyn30Gk0IYFnBFLhPIxxhXjJh0Lo3DhALG086gb0= X-Received: by 2002:a17:90a:f297:b0:2c9:84f9:a321 with SMTP id 98e67ed59e1d1-2cb37427edbmr174711a91.23.1721081155192; Mon, 15 Jul 2024 15:05:55 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 References: <3598c6db-6d8a-4efa-b5fc-1fc697608860@freebsd.org> <20240716063356.f0993ae6f7648ae19c1ae33f@dec.sakura.ne.jp> <0fb67778-d279-420b-b482-5ce36e08a1be@freebsd.org> In-Reply-To: <0fb67778-d279-420b-b482-5ce36e08a1be@freebsd.org> From: Warner Losh Date: Mon, 15 Jul 2024 16:05:44 -0600 Message-ID: Subject: Re: Change to FreeBSD release scheduling etc. To: Colin Percival Cc: Tomoaki AOKI , Peter , freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e2a936061d506e76" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WNGVX4rJJz4vs9 --000000000000e2a936061d506e76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2024 at 3:57=E2=80=AFPM Colin Percival wrote: > On 7/15/24 14:33, Tomoaki AOKI wrote: > > On Mon, 15 Jul 2024 11:58:16 -0700 > > Colin Percival wrote: > >> Extending the minor-release support period might be possible, but that > >> would depend on portmgr and secteam and I can't speak for them. One > issue > >> which would certainly come up is kernel module packages -- our package= s > >> are built for each stable branch on the oldest currently supported > release, > >> which means that e.g. new features in 14.1 can't be used until 14.0 is > EoL; > >> this is a problem particularly for graphics drivers. > > > > How do you think about flavorizing kmod ports in kmod.mk and provide > > pkgs for latest patch release (like 14.0-p8) of all supported > > point releases (like 14.0) [1]? > > Does it look possible and feasible? > > Rebuilding kernel modules for each patch level shouldn't be necessary. I= f > we break KBI in a security or errata update, something has gone > astonishingly > wrong. > > Flavouring kernel module ports for each minor release -- possibly buildin= g > 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. Ideally, we'd keep the same KBI per major release, but that ideal has falle= n short. Warner --000000000000e2a936061d506e76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 15, 2024 at 3:57=E2=80=AF= PM Colin Percival <cperciva@free= bsd.org> wrote:
On 7/15/24 14:33, Tomoaki AOKI wrote:
> On Mon, 15 Jul 2024 11:58:16 -0700
> Colin Percival <cperciva@freebsd.org> wrote:
>> Extending the minor-release support period might be possible, but = that
>> would depend on portmgr and secteam and I can't speak for them= .=C2=A0 One issue
>> which would certainly come up is kernel module packages -- our pac= kages
>> are built for each stable branch on the oldest currently supported= release,
>> which means that e.g. new features in 14.1 can't be used until= 14.0 is EoL;
>> this is a problem particularly for graphics drivers.
>
> How do you think about flavorizing kmod ports in kmod.mk and provide
> pkgs for latest patch release (like 14.0-p8) of all supported
> point releases (like 14.0) [1]?
> Does it look possible and feasible?

Rebuilding kernel modules for each patch level shouldn't be necessary.= =C2=A0 If
we break KBI in a security or errata update, something has gone astonishing= ly
wrong.

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?=C2=A0 But that's a question for portmgr; I don't k= now 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.

Ideally, we'd keep the same KB= I per major release, but that ideal has fallen
short.
<= br>
Warner=C2=A0
--000000000000e2a936061d506e76--