Why do some fixes in CURRENT dont end up in later RELEASE?

[chrcol]

I am looking at the reviews.freebsd.org site, and noticed a bunch of fixes related to igmp packets were committed to 14.0 CURRENT in December 2023. But then two of these fixes had to be added to 14.1 later in 2024. Is the code cherry picked or something, Quite curious about this.

One example here.

rGc2e340452c14

reviews.freebsd.org

rG88e1bc06692a

reviews.freebsd.org

 

[SirDice]

committed to 14.0 CURRENT in December 2023.

That would be 15.0-CURRENT at that time, not 14.0. 14.0-RELEASE was in November 2023, looks like stable/14 was branched off in July or August. That means main has to be 15.0 in December.

Is the code cherry picked or something

MFC'ed from -CURRENT to 14-STABLE, that's quite normal.

 

[Phishfry]

I don't know anything about this case but I have seen patches get committed to CURRENT but missed in STABLE.
RELEASES are culled from STABLE so patches might slip through the cracks sometimes and get added back in later.

MFC'ed from -CURRENT to 14-STABLE, that's quite normal.

As I understand it patches go in CURRENT first, then if all goes well you MFC it to STABLE.
Some newer hardware and features might not get a backport to STABLE. So its alot to keep track of.

 

[chrcol]

That would be 15.0-CURRENT at that time, not 14.0. 14.0-RELEASE was in November 2023, looks like stable/14 was branched off in July or August. That means main has to be 15.0 in December.


MFC'ed from -CURRENT to 14-STABLE, that's quite normal.

Ahh didnt know was already a 14.0 release at that date, thanks.

 

[mer]

As I understand it patches go in CURRENT first, then if all goes well you MFC it to STABLE.
Some newer hardware and features might not get a backport to STABLE. So its alot to keep track of.

Yep lots to keep track of. I think most of the time, new features don't get MFC'd, hardware maybe. I think it depends how much work. If it's add a couple of ids to a file because existing driver works in compatibility mode (like network or video devices) that usually happens because it's easy to do and it's easy to verify correctness.
Something that results in a crash probably older releases are looked to see if it needs fixing because a crash in CURRENT doesn't always mean the problem exists in previous RELEASE.
Security stuff is obviously fixed in all supported branches.

But that's only for the base, ports are completely different animal.

 

[SirDice]

One of the things to note is that -RELEASE versions are handed over to the security officer, they are not maintained by release engineering anymore. Only breaking issues may get fixed in existing -RELEASE versions (via Errata Notices). New features, drivers, and whatnot are always done in -CURRENT, some of those changes may get MFC'ed to -STABLE, which will then become part of the next minor release of that major version.

 

[cracauer@]

Also keep in mind that kernel API breaking changes are not allowed during a n-STABLE lifetime.

 

[Erichans]

Also keep in mind that kernel API breaking changes are not allowed during a n-STABLE lifetime.

Hmm, isn't that a bit overly strong? Isn't that intended as:
Also keep in mind that ABI changes are not allowed during a n-STABLE lifetime.

As to the kernel API, we've seen that with respect to the external graphics kernel modules, as in drm-X-kmod, in ports things have changed over the course of 14.0R->14.1R->14.2R. So, I'd say:
FreeBSD strives to keep its kernel API unchanged as much as possible over the lifetime of a supported major branch, such as 14/stable.

 

[mer]

But even if a kernel API/ABI remains unchanged between 14.1-RELEASE and 14.2-RELEASE, a kmod (like drm) built against 14.1-RELEASE has versioning related to 14.1-RELEASE so won't load on 14.2-RELEASE.
Isn't that basically the problem that folk are reporting at this point in time?

 

[cracauer@]

I think the idea is not not disable compilation of the same modules during a major release run. Recompilation might be required, though.