On what basis is development in Head/Current cascaded down to Stable?

[blazingice]

For the last few months I have been following 14-STABLE and have kept an eye on 15-CURRENT. As a newbie, I'm curious to understand on what basis the developments in 15-CURRENT are cascaded down to 14-STABLE.

To be more specific: Do all or some of the changes in current/15 cascade down to stable/14 after a number of weeks? Are there any changes that are only kept for the upcoming stable/15? What about the other stable branches (i.e. 13-STABLE and 12-STABLE) do they get similar updates to 14-STABLE? If selection/filtering takes place on what basis some of these decisions are made?

 

[T-Aoki]

My guess is as below.

• Basically changes breaking API/ABI and/or KPI/KBI compatibility would NOT merged to stable branches.
• KPI/KBI changes which does NOT affects kmods in ports and/or filesystems in ports, thus internal only changes could be merged.
• Non-breaking API/ABI changes could be merged. These are usually new functionality using spare (unused) elements in structs, enums etc.
• Deletions of known-to-be-used functions, variables, constants and/or macros would NOT merged.

Other changes depends purely on how the developer thinks/wants.

These means that POLA violations should be avoided within single stable branch, to keep binaries built for *.0-RELEASE sanely work for later releases from the same stable branch.
This is needed for pkg build cluster and official pkgs.
Without these restrictions, we need, for example, pkgs for 13.0, 13.1 and 13.2 must be built/provided independently, which means a huge amount of messes on build cluster and pkg repository.

 

[Andriy]

The most honest answer is that it is up to each individual committer.
Some try to merge most of their changes, some don't care.
Some calculate perceived risks and benefits of merging and do a merge after a period of time based on that balance.
Some just merge after a fixed period of time.
Some may be short on time for a long while.
Some may merge other's changes if they personally need them or if there is a dependency between changes.

There is no strict process, nobody gets fired, but there are some guidelines and rules.
T-Aoki listed some of the rules, if they are broken then a merge can get reverted.

 

[Cath O'Deray]

Relevant, but not an answer: <https://docs.freebsd.org/en/articles/committers-guide/#_considerations_when_mfcing>

Considerations when MFCing

From <https://docs.freebsd.org/en/articles/committers-guide/#_include_appropriate_metadata_in_a_footer>:

Relnotes:

If the change is a candidate for inclusion in the release notes for the next release from the branch, set to yes.

Gut feeling: the appropriateness was often overlooked. The command below might tell a different story.

git -C /usr/src log --no-expand-tabs --extended-regexp -i --grep='Relnotes:[[:cntrl:] ]{1,}yes'

 

[Cath O'Deray]

12-STABLE

The June 2023 CA roots might be a good example. From <https://old.reddit.com/r/freebsd/comments/18dzo1j/-/kcpmrxg/>:

• of the three versions that are supported by the Security Officer (12.⋯, 13.⋯, 14.⋯), the one that's closest to death is least likely be in focus for anything other than required errata notices and security advisories.

(Strictly speaking: six, not three, if we count STABLE and RELEASE as separate, but I wanted to be fairly concise there.)