[yocto] How to handle meta-intel/openembedded repos with multiple developers
mike.looijmans at topic.nl
Wed Nov 9 06:07:38 PST 2016
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:
> 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 ?
> Chris Z
> On Thu, Oct 27, 2016 at 8:22 AM, Edward Wingate <edwingate8 at gmail.com
> <mailto:edwingate8 at gmail.com>> wrote:
> On Thu, Mar 3, 2016 at 8:27 AM, Mark Hatle <mark.hatle at windriver.com
> <mailto:mark.hatle at 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
> > 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.
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans at topicproducts.com
Please consider the environment before printing this e-mail
> yocto mailing list
> yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
More information about the yocto