Solved updating a custom kernel

T

tOsYZYny

Hi - when updating a custom kernel, would it be a true statement that running git pull corresponds to stable whereas only pulling in the latest tag would be equivalent of running release?

In that case, since I am running release, then I should only use the tagged versions for the kernel source to accept the same level of risk / stability as the rest of the system, correct?
 
I apologize, I wasn't clear.

Yes, assuming I'm on the branch of interest, in this case releng/13.1, doing a git pull will update that branch. But, by taking all of the updates, that would be the equivalent of running 'stable', whereas if I just update to the latest tag, that would be the equivalent of 'release'?

So, in my case, while there are updates to 13.1, none of those were tagged, so there are no 'release' versions for that particular kernel, correct?
 
tOsYZYny said:
doing a git pull will update that branch.
Click to expand...
No, a git pull will update the whole git tree, including the branch you're on.

tOsYZYny said:
But, by taking all of the updates, that would be the equivalent of running 'stable', whereas if I just update to the latest tag, that would be the equivalent of 'release'?
Click to expand...
-STABLE is a different branch, stable/13 for example.

forums.freebsd.org

LTS support and version clarifications

Hello everybody, I have read the documentation for a while but have not been able to clarify my doubts. I will try to be as short as possible. At present according to this table: https://www.freebsd.org/security/#sup the latest LTS version is Stable 12. So if I wanted to have a long support I...
forums.freebsd.org forums.freebsd.org
 
No. in releng/* are only commits for the -RELEASE version. -STABLE is in a stable/* branch.

edit:
tOsYZYny said:
But, by taking all of the updates, that would be the equivalent of running 'stable', whereas if I just update to the latest tag, that would be the equivalent of 'release'?
Click to expand...
That's a misunderstanding about how git works. A tag is just a "mnemonic" for a specific commit. Updating to a tag is like updating to that specific commit, so it pulls all "parent" commits as well.
 
Ok, cool, then to keep my releng kernel up-to-date, I will merely pull the latest commits. Thanks, that keeps it simple.
 
I use the following script, you can do something similar
Code: 
rm -vfR /usr/src/* /usr/src/.??*
cd /usr/src/
git clone -o freebsd -b releng/13.1  https://git.FreeBSD.org/src.git    /usr/src
 
Thanks, I am using something similar. I am accustomed to teams cherry-picking commits to the release branch before finalizing the release with a tag. That is where my confusion lay.
 
I don't for updating my kernel, but was thinking if that were something I should do, then I would modify my script to find the latest tag on that branch and if there was a newer version, use that and rebuild ... but if you check: https://cgit.freebsd.org/src/log/?h=releng/13.1, you'll see that there is 1 tag, release/13.1.0.

In my day job, we cherry-pick commits to the release branch then when we're ready to release it, we 'cut a tag'. I guess in that sense, all of those commits have been tested, but normally together, there is some risk that taking a portion of those commits and not everything up until that tag may yield unpredictable results. Additionally, if we don't squash our commits into a single commit, that has the same consequences, we could be getting part of a patch and not the 'full' patch. I suppose it really depends on how things are done in kernel development is all.
 
Cherry-picking does happen. But that's mostly from main/master aka -CURRENT to a stable/X branch. Often referred to as an MFC, or Merged From Current.
 
Ok, so then I would say that when it is cherry-picked onto release that the commit is a stable unit of work that can be applied to production systems with little risk to their stability.
 
'stable' on FreeBSD has a slightly different meaning. It doesn't refer to the stability of the code, it refers to the stability of the ABI. main is were all things new happen, the main branch is -CURRENT (14.0 at this time). At some point a stable/X branch is branched off from main. From a stable/X branch a releng/X.Y is branched off. The stable/X branches are in essence the alpha of the next X.Y minor release.
 
The "layout" of (version control) branches reflects the FreeBSD support model. A significant changed was made in 2015: Changes to the FreeBSD Support Model. In version control terms: the HEAD or main branche is representative of FreeBSD -CURRENT. FreeBSD -STABLE and -RELEASE versions relate to individual branches. A nice overview is depicted here.

The FreeBSD support model is different from most other OS-es, as mentioned for example with the stable/X branche. Its version control branche hierachy and processes are set up to support that model and therefore may very well be different from the model and processes used by other software development environments.
 
Erichans said:
The "layout" of (version control) branches reflects the FreeBSD support model. A significant changed was made in 2015: Changes to the FreeBSD Support Model.
Click to expand...
FreeBSD used the same structure before that support model change. It changed which versions are supported, and for how long. It didn't change the branch structure of the source code, that remained the same.
 
You must log in or register to reply here.
Back
Top