Document process about upgrade buildroot and kernel #1049
Conversation
mattiaswal
force-pushed
the
document-kernel-buildroot-update
branch
from
d93c48f to
e08b702
Compare
| branches should contain **only** changes to existing packages (but no | ||
| new patches), modifications to Buildroot itself or upstream backports. |
There was a problem hiding this comment.
Probably obvious to those who understand, but to me it is not clear what "(but no new patches)" means. E.g., is it the "new" that is important, and "old patches" are ok?
And should "(but no new patches)" be put at the end of the sentence, or does it only apply to "existing packages"?
There was a problem hiding this comment.
Always a case by case, new is a (strict) guideline :D
mattiaswal
force-pushed
the
document-kernel-buildroot-update
branch
from
e08b702 to
5f01a50
Compare
| cd buildroot | ||
| ``` | ||
| 2. Pull the latest changes from KernelKit | ||
| ```bash | ||
| buildroot (2025.02.1-kkit)$ git pull | ||
| ``` | ||
| 3. Fetch the latest tags from upstream | ||
| ```bash | ||
| buildroot (2025.02.1-kkit)$ git fetch upstream --tags | ||
| ``` |
There was a problem hiding this comment.
There's a prompt (PS1) only on the last two examples. For consistency and to reduce confusion I suggest we prefix each prompt with ~/src $
| git clone git@github.com:kernelkit/buildroot.git | ||
| ``` | ||
|
|
||
| 2. Add the upstream remote | ||
| ```bash | ||
| git remote add upstream https://gitlab.com/buildroot.org/buildroot.git | ||
| ``` | ||
| 3. Checkout old KernelKit branch | ||
| ```bash | ||
| git checkout 2025.02.1-kkit | ||
| ``` | ||
|
|
There was a problem hiding this comment.
Here there are no prompts (PS1), and there's a missing cd buildroot, which is present in the first case.
| 4. Create a new branch based on the **previous** KernelKit Buildroot | ||
| release (e.g. `2025.02.1-kkit`) and name it according to the naming scheme (e.g. `2025.02.2-kkit`) | ||
| ```bash | ||
| buildroot (2025.02.1-kkit)$ git checkout -b 2025.02.2-kkit | ||
| ``` | ||
| 5. Rebase the new branch onto the corresponding upstream release | ||
| ```bash | ||
| buildroot (2025.02.2-kkit)$ git rebase 2025.02.2 | ||
| ``` | ||
| 6. Push the new branch and tags | ||
| ```bash | ||
| buildroot (2025.02.2-kkit)$ git push origin 2025.02.2-kkit --tags | ||
| ``` | ||
| 7. In Infix, checkout new branch of Buildroot | ||
| ```bash | ||
| infix (bump-buildroot)$ cd buildroot | ||
| infix/buildroot$ git fetch | ||
| infix/buildroot$ git checkout 2025.02.2-kkit |
There was a problem hiding this comment.
And now the prompts are back ... you get my point :-)
There's a similar section below this that has the exact same problems, so please have a look at that too.
| > **Note:** Note: Remember to set the pull request label to `ci:main` to ensure full CI coverage. | ||
|
|
||
| > **Note:** It is **not** allowed to rebase the branch when bumped in Infix. | ||
|
|
||
| #### Linux kernel |
There was a problem hiding this comment.
I suggest we use the new ghfm notice style https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#alerts
There was a problem hiding this comment.
And either collapse the two notes into one, or "spread them out" a bit for legibility.
| KernelKit maintains an internal [fork of Linux | ||
| kernel](https://github.com/kernelkit/linux), with branches following | ||
| the naming scheme `kkit-linux-[version].y`, e.g. `kkit-6.12.y`, which | ||
| means a new branch should be created whenever the major kernel version | ||
| is updated. This branch should | ||
| contain *all* kernel patches used by Infix. | ||
|
|
||
| KernelKit track the latest Linux kernel LTS (Long-Term Support) | ||
| release and updates. The upgrade of LTS minor releases is expected to | ||
| have low impact and should be done as soon as a patch release of the | ||
| LTS Linux kernel is available. | ||
|
|
There was a problem hiding this comment.
I suggest "reflowing" all paragraphs with M-q in Emacs so they are friendly to read also for those browsing the .md files directly.
| 6. Push changes | ||
| Commit and push the changes. Don’t forget to update the changelog. |
There was a problem hiding this comment.
In markdown rendering these two lines will be collapsed into one.
Also, s:changelog:doc/ChangeLog.md:
|
|
||
| 7. Create a pull request. | ||
|
|
||
| > **Note:** Remember to set the pull request label to `ci:main` to ensure full CI coverage. |
There was a problem hiding this comment.
Again, use ghfm markup for notes as mentioned above.
[skip ci]
Description
Checklist
Tick relevant boxes, this PR is-a or has-a: