Separate branches for LTS Yocto releases

[ramacassis]

Would it be possible to create distinct branches in the tibbo layers, to support at least the LTS Yocto releases?
Dunfell is coming to its end, so that would make kirkstone and scarthgap to maintain for the meta-* repositories.

The reason for this is that many Yocto based projects use repo or kas to fetch external layers during the build process.

With a specific branch we could avoid patching some files that currently lead to build errors.
Example with Kirkstone:
bb.parse.ParseError: ParseError at meta-sunplus/conf/machine/sp7021.conf:9: Could not include required file conf/machine/include/tune-cortexa9.inc

There are more complex approaches to branch management (meta-atmel or meta-ti could be great references), but they might be overkill

[dmitrydvorkin]

Yes, I'm going to do it.
There are only a couple of files that should be modified a bit for =Dunfell and >=Dunfell.
so I'm thinking about keeping the same branch, but renaming this files into
file.bb.dunfell
file.bb.kirkstone
and rename first or second into "file.bb" on fetch.
What do you think?

[ramacassis]

Thanks for being willing to take this extra step!

I am not aware of any git hooks for cloning.
Also, having different files version cohabit might work, but I think it could actually be more difficult to maintain/use in the long term 🙂

Some thoughts:

• If breaking changes are introduced in new versions, more files will have to be duplicated in the same branch.
  The latest example of this is the new override syntax which is not compatible with versions prior to Dunfell.
  It is also common that some variables are renamed, as we saw with Kirkstone release note.

• A single branch does not allow you to backport a fix to a specific version.
  You might end up with something like this:

* <- Kirkstone fix, but user cannot use it
|
* <- Scarthgap breaking change
|
* <- Kirstone support

On the other way, with the branch approach:

• When cloning, users only get the relevant files they need, which makes browsing easier.

• Layer is ready to use, and you can refer to the branch in your kas/repo config file directly.

• Displaying different branches also inform user that the version he is looking for is supported.
  I personally thought that only Dunfell was available, and had to look at the commits to realize this was not the case.

• You can stop supporting a branch by simply indicating it as EOL.
  This will be the case for Dunfell in some weeks, so this is the best time to start fresh IMO

[dmitrydvorkin]

two facts for meta-sunplus:

1. < Dunfell is not supported
2. current "dunfell" branch is ready and tested with kirkstone mickledore nanbield
   only two files should be updated:
   

   meta-sunplus/conf/machine/sp7021.conf

   Line 8 in 35e3878

   # Yocto branch: < Kirkstone

   
   

   meta-sunplus/conf/machine/sp7021-arm5.conf

   Line 8 in 35e3878

   # Yocto branch: < Kirkstone

for meta-tibbo it is a bit more complex: there are 3 files that should be patched before bitbaking... :)

[ramacassis]

Sure, I am already patching these two files locally by calling a script after fetch.

I was just a bit surprised I had to do these manual changes in the first place.
But I can live with this patch solution if the branch maintenance effort is too big, which I could also understand.
And if scarthgap (and the releases that will follow) do not introduce too many breaking changes, then it is still manageable.

Small question: you mentioned three files to patch on meta-tibbo. For now I only patched site.conf, did I miss some? (my migration is not complete yet, that could be the reason)

For meta-sunplus the README helped to find the changes to make, thanks for that.

[dmitrydvorkin]

I was just a bit surprised I had to do these manual changes in the first place

Yocto changed the cpu settings file location. If they would not do this then we would be 100% compatible with all new branches and not have to change anything in the files.

meta-tibbo layer have a couple of variable names that has been changed between Yocto branches.

Now I'm experimenting with branches locally, going to push the updates in next few days.
I'd rather use file names scheme I suggested before

[dmitrydvorkin]

There are nothing to do. Now it is compatible with Dunfell, Kirkstone, Nanbield AS-IS!
Although it is labelled as "dunfell" it doesn't require any modufications for building with this main branches of OE. The only thing you need is to update the preffered kernel version string for >= Nanbield - 5.4 kernel can't be build with this OE branch
Please, see my comment in the README:
https://github.com/tibbotech/meta-sunplus

[dmitrydvorkin]

Scarthgap is near to release, but not officially supported yet. It is upcoming release, I made tests. I saw a couple of minor issues - there are will not be a problem to update

[ramacassis]

Thanks for the update, the LAYERSERIES_CORENAMES looks nice!
I encountered some issues while migrating to Kirkstone, I will open some PRs to help fix them when I find time

[dmitrydvorkin]

And one more modification that helps you to get rid of complete ISP setup

eddf9d9