Regarding layers and their versioning.

Regarding layers and their versioning.

[Søren Holm]

Hello

What is the best way to manage a private repo with recipes as well as meta-oe, 
meta-core and meta-angstrom.

Currently I have a private repo that has the layers attached as submodules. Is 
that a crazy setup or what? ...... and while  I'm at it - which revision of 
all those layers are ment to match together? does master og meta-oe match 
master of meta-core or do they have simmilar tags/branches.

Thanks in advance.

-- 
Søren Holm

Re: Regarding layers and their versioning.

[Philip Balister]

On 10/20/2013 05:20 PM, Søren Holm wrote:
> Hello
> 
> What is the best way to manage a private repo with recipes as well as meta-oe, 
> meta-core and meta-angstrom.
> 
> Currently I have a private repo that has the layers attached as submodules. Is 
> that a crazy setup or what? ...... and while  I'm at it - which revision of 
> all those layers are ment to match together? does master og meta-oe match 
> master of meta-core or do they have simmilar tags/branches.
> 
> Thanks in advance.
> 

If it works well for you, it must be a good idea. I've also heard of
people using repo.

Philip

Re: Regarding layers and their versioning.

[Anders Darander]

"Søren Holm" <sgh@sgh.dk> wrote:
>Hello
>
>What is the best way to manage a private repo with recipes as well as
>meta-oe, 
>meta-core and meta-angstrom.

>Currently I have a private repo that has the layers attached as
>submodules. Is 
>that a crazy setup or what?

We're doing the same internally at ChargeStorm. One benefit is that we're having our "master" repo keeping track of all the layers that we're using and which revision of those layers. 

Other people / projects just use a shell script checking out the desired layers. Some people combines layers into one huge repo (though I'd personally not recommend that approach). (That'd be similar to how Poky is being managed). 

Yet other people / projects use repo. 

It's up to what you're comfortable with in the end. 

> ...... and while  I'm at it - which
>revision of 
>all those layers are ment to match together? does master og meta-oe
>match 
>master of meta-core or do they have simmilar tags/branches.

Yes, in general master of all (most) layers are intended to be used with master from oe-core. Most layers k att least bigger and more used ones) try to support a few old releases, and typically do this using the same branch name as used in oe-core. 

Cheers, 
Anders 

-- 
ChargeStorm AB / eStorm 

Re: Regarding layers and their versioning.

[Paul Eggleton]

On Monday 21 October 2013 09:29:27 Anders Darander wrote:
> "Søren Holm" <sgh@sgh.dk> wrote:
> >What is the best way to manage a private repo with recipes as well as
> >meta-oe,
> >meta-core and meta-angstrom.
> >
> >Currently I have a private repo that has the layers attached as
> >submodules. Is that a crazy setup or what?
> 
> We're doing the same internally at ChargeStorm. One benefit is that we're
> having our "master" repo keeping track of all the layers that we're using
> and which revision of those layers.
> 
> Other people / projects just use a shell script checking out the desired
> layers. Some people combines layers into one huge repo (though I'd
> personally not recommend that approach). (That'd be similar to how Poky is
> being managed).
>
> Yet other people / projects use repo. 
>
> It's up to what you're comfortable with in the end. 

Just to clarify, we use the combo-layer script (scripts/combo-layer) to manage 
the Poky repository. It can combine multiple repositories or even parts of 
repositories into one and keep it up-to-date. It works well for our purposes, 
i.e. providing a single repository that people can download containing all of 
the needed basic components. However, it's just one of a number of different 
solutions in this area and you'd have to evaluate which tool works best for 
your situation.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Regarding layers and their versioning.

[Burton, Ross]

On 21 October 2013 09:29, Anders Darander <anders@chargestorm.se> wrote:
> We're doing the same internally at ChargeStorm. One benefit is that we're having our
> "master" repo keeping track of all the layers that we're using and which revision of
> those layers.

Guacamayo uses a master repository with submodules for each layer.
Works nicely as the layers are pinned to revisions which are known to
work, and then branches can be made to integrate upgraded layers.

Ross

Re: Regarding layers and their versioning.

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]

On Mon, Oct 21, 2013 at 09:29:27AM +0100, Anders Darander wrote:
> 
> 
> "Søren Holm" <sgh@sgh.dk> wrote:
> >Hello
> >
> >What is the best way to manage a private repo with recipes as well as
> >meta-oe, 
> >meta-core and meta-angstrom.
> 
> >Currently I have a private repo that has the layers attached as
> >submodules. Is 
> >that a crazy setup or what?
> 
> We're doing the same internally at ChargeStorm. One benefit is that we're having our "master" repo keeping track of all the layers that we're using and which revision of those layers. 
> 
> Other people / projects just use a shell script checking out the desired layers. Some people combines layers into one huge repo (though I'd personally not recommend that approach). (That'd be similar to how Poky is being managed). 
> 
> Yet other people / projects use repo. 
> 
> It's up to what you're comfortable with in the end. 

I was using Makefile to checkout correct set of layers with correct
revisions for SHR before and then changed it to use layerman script
very similar to script used in angstrom-setup-scripts, because
layers.txt is more "declarative" and easier to update than what I had
in Makefile.

For webos-ports project I use the same.

For webos we recently switched from repo with submodules to repository
with similar script (mcf - this time in python). Mostly because repos
with submodules don't work well when replicating from gerrit to github.

I think that biggest advantage of solution with some script, is that
layers are still standalone checkouts, which developers can use as any
other project (easier to submit patches upstream etc).

And the script
can be more clever than git pull --rebase in repo with submodules, e.g.
for jenkins builds I want to automatically update build configuration in
non-interactive way (because jenkins shouldn't ever keep some local
changes), but for local build I want to preserve developer's local.conf
changes and e.g. extra layers added in bblayers.conf etc.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Regarding layers and their versioning.

[Otavio Salvador]

On Mon, Oct 21, 2013 at 7:01 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Monday 21 October 2013 09:29:27 Anders Darander wrote:
>> "Søren Holm" <sgh@sgh.dk> wrote:
>> >What is the best way to manage a private repo with recipes as well as
>> >meta-oe,
>> >meta-core and meta-angstrom.
>> >
>> >Currently I have a private repo that has the layers attached as
>> >submodules. Is that a crazy setup or what?
>>
>> We're doing the same internally at ChargeStorm. One benefit is that we're
>> having our "master" repo keeping track of all the layers that we're using
>> and which revision of those layers.
>>
>> Other people / projects just use a shell script checking out the desired
>> layers. Some people combines layers into one huge repo (though I'd
>> personally not recommend that approach). (That'd be similar to how Poky is
>> being managed).
>>
>> Yet other people / projects use repo.
>>
>> It's up to what you're comfortable with in the end.
>
> Just to clarify, we use the combo-layer script (scripts/combo-layer) to manage
> the Poky repository. It can combine multiple repositories or even parts of
> repositories into one and keep it up-to-date. It works well for our purposes,
> i.e. providing a single repository that people can download containing all of
> the needed basic components. However, it's just one of a number of different
> solutions in this area and you'd have to evaluate which tool works best for
> your situation.

At O.S. Systems we used some variants here.

We started with forking and moved to combo-layer script. The
combo-layer works for most case but it fails badly with empty merge
commits and like. So it works quite fine for Yocto use case but not as
fine for company workflow.

In the end we choose 'repo' and we provide some 'platform' for
customers where we link all need projects in a single .xml file; this
scales fine and is quite easy to use.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Regarding layers and their versioning.

[Søren Holm]

Thanks for your replies. It was very reassuring that I'm not doing the wrong 
thing.

-- 
Søren Holm