Re: Change to FreeBSD release scheduling etc.

I think the "rush to merge stuff into FreeBSD" concern that Colin was speaking about is valid, and it's actually the situation that the Linux kernel finds itself in all the time. They tend to have a relatively fast development 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 months. The Linux kernel does have a lot more activity than FreeBSD/kernel, so it's possible we may not need to put too much emphasis on a strategy to solve that particular point. Which also means developers can/should still wait 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 during which new major features are introduced into the kernel
    after the merge window closes, there is a 7-week bugfix and stabilization period with weekly "release candidate" snapshots
    rc7 is usually the last release candidate, though occasionally there may 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,
>  
>   thank You all for the feedback. As it seems. I'm not the only one
>  concerned.
>  
>  On Mon, Jul 15, 2024 at 11:58:16AM -0700, Colin Percival wrote:
>  
>  > 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.
>  
>  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.
>  
>  > 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.
>  
>  It concerns secteam, certainly. Maybe you can speak /to/ them... ;)
>  
>  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.
>  
>  
>  regards,
>  PMc
>  
>