Re: Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?

Khem Raj

On Thu, Apr 29, 2021 at 3:32 PM Martin Jansa <martin.jansa@...> wrote:

On Thu, Apr 29, 2021 at 06:05:30PM -0400, Randy MacLeod wrote:
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?
Hi Armin,

The community will fix bugs on HEAD just like before.
It's a tag indicating where the branch was at GA time.
There's no obligation for he maintainer do do anything in addition
to what they were doing if we didn't have a tag.

I guess that could be made clear in the README if needed.
To be honest I don't see much value of these tags for layers not
included in the QA testing with oe-core release.

I believe we agreed on promoting latest revisions in the branches for
selected release.

And I think the process for stable branches works reasonably well in the
layers I usually use and only very rarely new regression is introduced
in stable branch so from my experience the latest revision is always better
than GA tag (or any tag for various point releases).

Why should anyone use yocto-3.3 tag of meta-oe if the harknott branch
has few more fixes and tip of hardknott branch was tested exactly the
same as the yocto-3.3 tag?

TLDR: Why should some low traffic layer have these tags which might point to
exactly the same commit for multiple release (when all of them
still parse, build and work correctly). Many layers don't feel the need
to create a separate branch for each release when the same master works
fine for last 3 Yocto releases. And I feel the pain when e.g. with
meta-ros the last 4 branches (dunfell, gatesgarth, hardknott, master)
are 99% identical, so whatever ROS update I merge to one of them gets
distributed across all of them and only rarely with some small
modification added only in some of them. Adding a yocto-3.3 tag there
won't make that commit any better than a tip of hardknott and it might
be actually a lot worse than tip of hardknott.
I think its perhaps also that distros have mechanisms to lock layers at a given
revision whatever tooling they use ( git submod, android repo,
combotools something else)
so distro manifest at that point acts as pseudo tag and seems better
downstream way
to create a uniform tested view of that distro. Something similar is
needed for poky distro perhaps a layer manifest
which tells about revisions of tested layers with poky version X if we
desire to have more layers tested along with what it supports as of
oe-core supports nodistro and its self-sufficient.


Join to automatically receive all group messages.