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".
Click to expand...
 
gotnull said:
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.
Click to expand...
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.
 
zoltan said:
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?
Click to expand...
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.
 
gotnull said:
I won't mention or link
Click to expand...

Smart move, thank you.

Mayhem30 said:
Any ideas what the issue is?
Click to expand...

Here, without argument-generating links or text:

1715002230675.png
 
SirDice said:
… it'll make quite a few people happy because graphics/drm-61-kmod can be installed.
Click to expand...

zoltan said:
… What does this change do differently from what's in FreeBSD 14.0 now?
Click to expand...

beetreetime said:
… pleased that they expedited the necessary changes for that.
Click to expand...

Changes were made in February:

1715002673170.png


zoltan said:
Will this graphics/drm-61-kmod thing make old graphics cards like HD4000 work better?
Click to expand...

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.
 
Last edited:
jardows said:
… does anyone have a good link to other notable updates?
Click to expand...

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: 255
gotnull said:
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.
Click to expand...

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.
 
richardtoohey2 said:
From Twitter, Colin Percival:
Click to expand...

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: 264
  • 1715024077286.png
    1715024077286.png
    88.1 KB · Views: 232
  • 1715024226834.png
    1715024226834.png
    32.5 KB · Views: 251
reddy said:
… maybe a bit too long at times.
Click to expand...

releng/14.0 was extraordinary, technically.

mer said:
… My opinion it starts with defining "what's in this release" …
Click to expand...

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: 247
  • Like
Reactions: mer
Cath O'Deray said:
At least: everything that was on stable/14 before the creation of releng/14.1.
Click to expand...
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).
 
You must log in or register to reply here.
Back
Top