14.1 is coming

About the release of 14.1 I've read a comment from Colin Percival on a social media (that I won't mention or link in order to avoid a war) that he wants to accelerate the releases dates to satisfy the devs.
[...] one of my goals as the new release engineering lead is to speed up the release cadence so that we don't have developers saying "I really need to get my code into this release because otherwise I'll have to wait a long time for the next one".
 
About the release of 14.1 I've read a comment from Colin Percival on a social media (that I won't mention or link in order to avoid a war) that he wants to accelerate the releases dates to satisfy the devs.
As long as basic code review doesn't get overlooked giving us nasty surprises, I don't see this as a bad thing. -STABLE and -CURRENT tend to be very stable these days. With the increase in new hardware support that often does not officially get released until the next point release, accelerating the cadence will help keep those of us who like to run -RELEASE able to keep up better with the hardware.

Edit: Other than the updated drm-kmod, does anyone have a good link to other notable updates?
 
Slightly newer OpenZFS version got imported too.

14-STABLE system:
Code:
root@molly:/usr/src # zfs -V
zfs-2.2.3-FreeBSD_gc883088df
zfs-kmod-2.2.3-FreeBSD_gc883088df
14.0-RELEASE:
Code:
dice@fbsd-test:~ % zfs -V
zfs-2.2.0-FreeBSD_g95785196f
zfs-kmod-2.2.0-FreeBSD_g95785196f

I'm trying to wade through a gazillion commits looking for some specifics I can report. Don't think there's a neat overview just yet.
 
Apologies for the silly question. What does this change do differently from what's in FreeBSD 14.0 now? Will this graphics/drm-61-kmod thing make old graphics cards like HD4000 work better?
The number is the Linux version the DRM drivers are taken from (so here Linux 6.1). Very short and simplified explanation: These drivers are maintained inside Linux, but are liberally licensed (IIRC MIT), so FreeBSD uses them as well and just works on the necessary adapter code to make them work with the FreeBSD kernel.

Therefore, the best answer to this sort of question should be Linux release notes ;)

It's generally less likely that drivers for very old GPUs get much love, the focus is probably more on support for newer ones.
 
I'm assuming there have been some unexpected delays with 14.1? The release schedule stops on April 8th.

Any ideas what the issue is?

 
I won't mention or link

Smart move, thank you.

Any ideas what the issue is?

Here, without argument-generating links or text:

1715002230675.png
 
… it'll make quite a few people happy because graphics/drm-61-kmod can be installed.

… What does this change do differently from what's in FreeBSD 14.0 now?

… pleased that they expedited the necessary changes for that.

Changes were made in February:

1715002673170.png


Will this graphics/drm-61-kmod thing make old graphics cards like HD4000 work better?

Not necessarily. The higher number relates to the version of a Linux kernel.

Loosely speaking, a more modern kernel means support broadened for more modern hardware.
 
… does anyone have a good link to other notable updates?

I have a link to what's published but honestly, not worth sharing; it's too soon for the release notes to be more than a template.

In social media, we have a recent plea from the FreeBSD Primary Release Engineering Team Lead to test something.

Pictured: his less recent comment, with a smile, about people sharing :)
 

Attachments

  • 1715003311362.png
    1715003311362.png
    89.8 KB · Views: 55
Please: where, exactly, was the audio context apparent?

From Twitter, Colin Percival:

”FreeBSD 14.1-BETA1 is now available: lists.freebsd.org/archives/freeb…

Please test this! Especially if you have a desktop/laptop system -- some changes just landed recently affecting audio and we'd like to make sure nothing broke (if necessary we'll pull them from 14.1).”
 
About the release of 14.1 I've read a comment from Colin Percival on a social media (that I won't mention or link in order to avoid a war) that he wants to accelerate the releases dates to satisfy the devs.

I hope they won't move too fast though so that users do not feel pressured to update every two weeks for example. The current point release tempo felt like a good balance, maybe a bit too long at times.
 
  • Like
Reactions: mro
release vs dates.
It's always a tradeoff.
My opinion it starts with defining "what's in this release"
Bugfixes? Make sure they are root caused so fixes can be tested (sometimes just code inspection). I think bugfixes can come quicker, but root cause is key. Prioritize bugs also needs to happen.
Features? We all want new features but features take a wider test audience than bugfixes and one has to avoid "feature creep" "Well we should bring in this other thing". Feature creep usually winds up delaying release for one more thing.
 
From Twitter, Colin Percival:

Similarly, but without the walled garden effect that's now associated with X, Colin's post pictured below (first shot).

Third shot, the omission of X was probably unintentional. If it's perceptibly a problem, I can raise it with Drew Gurkowski in Discord (he recently fixed a mistake in the Netflix case study, which was identified through discussion in a programming community on social media).
 

Attachments

  • 1715023848554.png
    1715023848554.png
    215.2 KB · Views: 35
  • 1715024077286.png
    1715024077286.png
    88.1 KB · Views: 34
  • 1715024226834.png
    1715024226834.png
    32.5 KB · Views: 37
… maybe a bit too long at times.

releng/14.0 was extraordinary, technically.

… My opinion it starts with defining "what's in this release" …

At least: everything that was on stable/14 before the creation of releng/14.1.

Whether there should be a merge from main is typically decided before the commit to main. So that is, largely, where it's defined.

Below, the private conversation between the fourth and fifth comments was about the sound-related enhancements, which, I'm extremely glad to say, were brought forward (without the originally planned wait of two months).
 

Attachments

  • 1715025335246.png
    1715025335246.png
    141.5 KB · Views: 42
  • Like
Reactions: mer
At least: everything that was on stable/14 before the creation of releng/14.1.
Which is generally why I have at least one system running -STABLE. So I know what's ahead for the next minor releases.

And I'm used to building world any way, for a long time this was the only way to update (freebsd-update(8) was introduced in 9.0 I believe).
 
Back
Top