Re: Change to FreeBSD release scheduling etc.

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