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


Randy MacLeod
 

Adding Robert, Hongxu and Qi who are likely interested in this topic
for future releases.

On 2021-04-27 3:03 p.m., akuster808 wrote:
On 4/27/21 9:48 AM, 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.
So the official starting point is what you are looking for?
Yes. It's always bothered me that the tag wasn't there and now
that oe-core/bitbake/... have been doing it, it would be nice to see
other layers add the start-of-release tag. Usually, it's clear
since you can find the first commit that is unique to the branch.
It's often an update to a README or a layer.conf file that you can find
using 'git merge-base' but the tag will make it simple to locate and
in the case of meta-oe, where the branch came well before the oe-core release, the tag may not be the first commit on the 'hardknott' branch.



Is there any
expectation to tag for dot release alignment?
It would be really nice to have but it's less important to me at least.
What do you think of tagging dot upcoming releases for
meta-oe/dunfell Armin?


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.
What's more important, tag or branch? Many layers hosted on git.yp.org
don't have the 'hardknott' branch.  If the discipline to create a new
branch is not their, I have a hard time believing 'tagging' will be high
on their list.
I don't expect 100% of layers to do this but hopefully maintatiner will
listen users/submitters we'll get some traction. Also for those layers
that don't want to maintain a branch they *might* not mind adding
the tag to at least record where they were when Yocto branched.



Are there any concerns about attempting to do this for yocto-3.3
and later?
Tagging in Poky has a meaning of a fully QA set of sources at a given
point of time.  It may be interpreted by users that if a tag showed up
in other layers, those layers are also fully tested.
I suppose but once people are around for a while, they'll come to
understand how other layers don't go through the same QA cycle.



Should we make it a requirement for yocto compliance?
I think you mean 'Yocto Compatible'.
Right.

Branching is already a requirement
IIRC as the program is against a specific branch.
Yes, this would be an additional requirement or request.
The benefits that I see I've mostly already explained but
I also like having a numerical uniform string that I can us
to remember the pseudo-random branch names! :)


Thanks for the comments Armin.

../Randy

-armin

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

--
# Randy MacLeod
# Wind River Linux

Join yocto@lists.yoctoproject.org to automatically receive all group messages.