Date: Tue, 16 Jul 2024 20:48:47 +0000 From: Jonathan Vasquez <jon@xyinn.org> To: "pmc@citylink.dinoex.sub.org" <pmc@citylink.dinoex.sub.org>, "cperciva@freebsd.org" <cperciva@freebsd.org> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: Change to FreeBSD release scheduling etc. Message-ID: <_HuyEsRX_mI0SJbTeeDWkH1y8eteJAHXJlUg6w09I7J77Ln8sJJnE0e57FLH9d5_MkN080FVlfMiLyeZvV08R7bHuebiiScYsnOr8XywOmA=@xyinn.org> In-Reply-To: <ZpbAzg_FT-0S6Rue@disp.intra.daemon.contact> References: <ZpPCADUpmCFHNa49@disp.intra.daemon.contact> <3598c6db-6d8a-4efa-b5fc-1fc697608860@freebsd.org> <ZpbAzg_FT-0S6Rue@disp.intra.daemon.contact>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <pmc@citylink.dinoex.sub.org> 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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?_HuyEsRX_mI0SJbTeeDWkH1y8eteJAHXJlUg6w09I7J77Ln8sJJnE0e57FLH9d5_MkN080FVlfMiLyeZvV08R7bHuebiiScYsnOr8XywOmA=>