Git submodules work fine for this.

In general, for each project I create a top-level repo that has the OE repos as submodule. The project repo also contains the project-specific recipes.


On 07-11-16 20:31, Chris Z. wrote:
Hi,

How you store your project configuration ? How you prepare workspace (download
each layer separately)?
Basic stuff, SW release should be reproducible (in easy way). Store somewhere
used hash of each piece or use tags. Non company assets should be already
somehow tagged or you use HEAD or master/-next ?

Br,
Chris Z

On Thu, Oct 27, 2016 at 8:22 AM, Edward Wingate <edwinga...@gmail.com
<mailto:edwinga...@gmail.com>> wrote:

    On Thu, Mar 3, 2016 at 8:27 AM, Mark Hatle <mark.ha...@windriver.com
    <mailto:mark.ha...@windriver.com>> wrote:
    >  At some point during product development a lead/architect needs to make 
the
    > decision to 'freeze' development and at that point everything is
    tagged/branched
    > and only backports are used from them on.  (If the number of backports
    gets too
    > large, you MIGHT decide to selectively rebase.)

    I'm currently trying to figure out with how to control external layers
    in my Yocto build and found this thread.  I'm a little unclear on how
    to track a release to the version used on non-company layers.  Say I'm
    using poky, meta-openembedded, meta-xilinx and then my own layer,
    meta-me. When I freeze development and do a release, I can tag
    meta-me, but because I also treat non-company assets as RO, I
    shouldn't tag poky, meta-openembedded nor meta-xilinx (or should I? Is
    this where I use git's lightweight tagging as opposed to annotated
    tags?) When "everything is tagged/branched", does that somehow include
    tagging the non-company assets?  Thanks for any help.

    Ed
    --

Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





_______________________________________________
    yocto mailing list
    yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
    https://lists.yoctoproject.org/listinfo/yocto
    <https://lists.yoctoproject.org/listinfo/yocto>





--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to