On Tue, Apr 27, 2021 at 9:48 AM Randy MacLeod <randy.macleod@...> wrote:
Hi,
I've CCed some of the maintainers of more widely used Yocto layers to get comments on about tagging. Please add in people who I may have missed.
For a while now, oe-core has had a yocto-X.Y tag in addition to the release branch name. This helps users easily find the exact commit that corresponds to the say 3.3 GA release. There have been some omissions in tagging but Michael and Richard are adjusting the release process so that tagging will happen more consistently.
Most yocto layers have not adopted the tagging perhaps because they weren't aware of it so that's why I'm writing this email. Tagging will make it easy to find the first commit for a specific release independent of what the branching policy of a layer is. Layer maintainers sometimes create the release branch in advance of when oe-core is released and by adding the tag, it would make it clear when the layer considers content to be officially released. Of course it's up to users to decide if they are going to follow the HEAD of a branch or, for some reason, stick with a tagged commit or private branch off that commit.
I think this could be a good thing, although it does put the burden on release maintainers. mostly they test against the tip of the release branch, So if yocto project testing is including these layers for wider testing and can then recommend a validated commit then perhaps this could be made viable.
That could open up a can of worms as who will fix the QA test failures?
-armin
Are there any concerns about attempting to do this for yocto-3.3 and later?
Should we make it a requirement for yocto compliance? Should it be a feature tested by the yocto compliance script?
Here's what's in oe-core and bitbake now: $ cd .../oe-core.git $ git tag -l | grep yocto-3 yocto-3.0 yocto-3.1 yocto-3.1.7 yocto-3.2 yocto-3.2.1 yocto-3.3
$ cd bitbake/ $ git tag -l | grep yocto-3 yocto-3.0 yocto-3.1 yocto-3.2
