From nobody Mon Jul 15 21:33:56 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 4WNFpP3ld3z5QDbT for ; Mon, 15 Jul 2024 21:34:37 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4WNFpN5hSdz4pcr; Mon, 15 Jul 2024 21:34:36 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 46FLXuaT054753; Tue, 16 Jul 2024 06:33:56 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1721079238; bh=4hnkI6joAn2XAMrDCES601aA0d9BmuOH60UT2HIR9bc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=m1WUx2YfQ+JFZSYVdCZVQYnS9PT08Gvt/MBw1sEkgK9q48yV/K0gzq6xe2xxCrwby qLBMHI6kBU0RVjwVHUT9bAXAf6GUQ4GRjwGmg1cYOvzIJl/lQ7ifPuSnK0QYGGk/MJ IHAp3+OE09d2ADJmkZ3AXiEoWkGpPnd1f2rxgY2M= Date: Tue, 16 Jul 2024 06:33:56 +0900 From: Tomoaki AOKI To: Colin Percival Cc: Peter , freebsd-stable@freebsd.org Subject: Re: Change to FreeBSD release scheduling etc. Message-Id: <20240716063356.f0993ae6f7648ae19c1ae33f@dec.sakura.ne.jp> In-Reply-To: <3598c6db-6d8a-4efa-b5fc-1fc697608860@freebsd.org> References: <3598c6db-6d8a-4efa-b5fc-1fc697608860@freebsd.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4WNFpN5hSdz4pcr On Mon, 15 Jul 2024 11:58:16 -0700 Colin Percival wrote: > On 7/14/24 05:18, Peter wrote: > > In short, it takes me about 3 months to catch the surprizes[*] and fix > > (or find out how to cope with) the concerning issues, regressions et > > al. that come along with a new release. Up to now that would then give > > another 9 months during which the systems can be operated in a > > plan-of-record fashion, until the next release starts the hassle > > again. > > While I see your point, we're hoping that having roughly 2x as many minor > releases will result in at least a 2x reduction in the number of surprises > per minor release -- because not only is less code changing between minor > releases, but also committers feeling less pressure to hit a deadline may > result in code being better tested and less surprise-prone when it lands > in a minor release. > > > Thinking about what could be done for remedy, what comes to my mind > > most easily is, simply support two most recent releases, so people > > get the option to skip each other upgrade. That doesn't look like much > > work, basically just backporting occasional security fixes. > > So much as a spontaneous suggestion. > > 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 packages > 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. Hi. 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? I think main and stable branch users would rebuild kmods habitally, so providing kmods for supported releases may be sufficient. [1] https://forums.freebsd.org/threads/cant-log-in-with-graphics-drm-515-kmod.94155/#post-662490 > > -- > Colin Percival > FreeBSD Release Engineering Lead & EC2 platform maintainer > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid -- Tomoaki AOKI