From nobody Tue Jul 16 20:48:47 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 4WNrlF2fnXz5QCyv for ; Tue, 16 Jul 2024 20:48:57 +0000 (UTC) (envelope-from jon@xyinn.org) Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WNrlD0L8Yz4GMj; Tue, 16 Jul 2024 20:48:54 +0000 (UTC) (envelope-from jon@xyinn.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xyinn.org; s=protonmail; t=1721162932; x=1721422132; bh=nMOTmLoVTVCsca0F4+YkBnPL2FvkwQtPauJNhR3fBsA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Iy59MnABXLhPNnGapRN2SYofq53dBhGbcUYkO7QSZuidcmgTai/PORlbab/oHZOaO TWuN2OxLaTitdz/uDMRY+0HsHOOFr3k1DYERqq4oc7NdLFqdy2vZH8kTgRhw/PTZd7 aTJTl/EHhFSpC5nVbTirFopJMC9d9DVhd/OVMhcLaYTL+AgbVzBIDuzIVY6Wra5nWf ZcqSMscpqm23BifMqi7aQkmLVwIu27TUZG1RfgjLJkZlaCnnnTY2Rmuyzah+ezfuxe 82g4EGoTUd6EpueL9mlf2WguM+GChdgs9RFEyYy3wT5QRjEWOvtOKgeYuCejES3wjm LHzDEfmFIa+Fg== Date: Tue, 16 Jul 2024 20:48:47 +0000 To: "pmc@citylink.dinoex.sub.org" , "cperciva@freebsd.org" From: Jonathan Vasquez Cc: "freebsd-stable@freebsd.org" Subject: Re: Change to FreeBSD release scheduling etc. Message-ID: <_HuyEsRX_mI0SJbTeeDWkH1y8eteJAHXJlUg6w09I7J77Ln8sJJnE0e57FLH9d5_MkN080FVlfMiLyeZvV08R7bHuebiiScYsnOr8XywOmA=@xyinn.org> In-Reply-To: References: <3598c6db-6d8a-4efa-b5fc-1fc697608860@freebsd.org> Feedback-ID: 12351801:user:proton X-Pm-Message-ID: 6f60817a4a6b5e57942690b36a8d6969a85d6aff 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=utf-8 Content-Transfer-Encoding: quoted-printable 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:62371, ipnet:185.70.40.0/24, country:CH] X-Rspamd-Queue-Id: 4WNrlD0L8Yz4GMj I think the "rush to merge stuff into FreeBSD" concern that Colin was speak= ing about is valid, and it's actually the situation that the Linux kernel f= inds itself in all the time. They tend to have a relatively fast developmen= t cycle (2-3 months) because of this, and even with that people will still = want to merge stuff in because they don't want to wait until another 2-3 mo= nths. The Linux kernel does have a lot more activity than FreeBSD/kernel, s= o it's possible we may not need to put too much emphasis on a strategy to s= olve that particular point. Which also means developers can/should still wa= it for the next release. Below is a quote of the current release policy on kernel.org for thought: When is the next mainline kernel version going to be released? Linux kernel follows a simple release cadence: after each mainline release, there is a 2-week "merge window" period du= ring which new major features are introduced into the kernel after the merge window closes, there is a 7-week bugfix and stabilizati= on period with weekly "release candidate" snapshots rc7 is usually the last release candidate, though occasionally there ma= y be additional rc8+ releases if that is deemed necessary So, to find the approximate date of the next mainline kernel release, take = the date of the previous mainline release and add 9-10 weeks. https://www.kernel.org/category/releases.html Jonathan Vasquez PGP: 34DA 858C 1447 509E C77A D49F FB85 90B7 C4CA 5279 Sent with ProtonMail Secure Email -------- Original Message -------- On 7/16/24 14:49, Peter wrote: > Folks, > =20 > thank You all for the feedback. As it seems. I'm not the only one > concerned. > =20 > On Mon, Jul 15, 2024 at 11:58:16AM -0700, Colin Percival wrote: > =20 > > While I see your point, we're hoping that having roughly 2x as many mi= nor > > releases will result in at least a 2x reduction in the number of surpr= ises > > per minor release -- because not only is less code changing between mi= nor > > releases, but also committers feeling less pressure to hit a deadline = may > > result in code being better tested and less surprise-prone when it lan= ds > > in a minor release. > =20 > That sounds nice, I just do not believe it: the surprizes which I > happen to encounter, do not appear as having been created in a hurry of > pressing release date. > Also, the Agile/Devops/etc theorists teach to release often and with > small increments. So what will most likely happen is just smaller > increments, again in a hurry, to meet the release date. > =20 > > 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 i= ssue > > which would certainly come up is kernel module packages -- our package= s > > are built for each stable branch on the oldest currently supported rel= ease, > > 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. > =20 > It concerns secteam, certainly. Maybe you can speak /to/ them... ;) > =20 > The ports issue seems rather a technical shortcoming insofar as kernel > modules may need recompile for minor releases, while the pkg > infrastructure has no notion of a minor release. > This is a pain-point already: I remember frequent discussions in the > forums whenever a new minor release appears and something with the > graphics driver doesn't work as expected (I don't know the details, > as I for my part do deploy from source.) > An improvement with this might be desireable anyway and independent > from the release schedule. > =20 > =20 > regards, > PMc > =20 >