[RFC] meta-openembedded layer for yocto hosted on oe.org

[RFC] meta-openembedded layer for yocto hosted on oe.org

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I've locally split
http://gitorious.org/angstrom/angstrom-layers/commits/master into 3
seperate git repos with git-filter-branch. I would like to move the
meta-openembedded layer to the OE git server to make it easier for
others to help in cleaning it up and getting more use to layers. The
beagle and angstrom layers could move there as well, but those will need
a more restricted set of committers.

In essence I would like this to be the "official" OE layer for yocto
while the board is dealing with the yocto negotiations.

This would be a good chance to try out things like 'maintainers' and
'pull requests' if we wanted to :)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFND3wGMkyGM64RGpERAspRAKCQS+ZtZqw/my9oTZ8l+O4KqD+WDQCcDeij
7XzhyxcmFBpGtwWwGZC7QT0=
=EH9g
-----END PGP SIGNATURE-----

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Graeme Gregory]

On 20/12/2010 15:53, Koen Kooi wrote:
> Hi,
>
> I've locally split
> http://gitorious.org/angstrom/angstrom-layers/commits/master into 3
> seperate git repos with git-filter-branch. I would like to move the
> meta-openembedded layer to the OE git server to make it easier for
> others to help in cleaning it up and getting more use to layers. The
> beagle and angstrom layers could move there as well, but those will need
> a more restricted set of committers.
>
> In essence I would like this to be the "official" OE layer for yocto
> while the board is dealing with the yocto negotiations.
>
> This would be a good chance to try out things like 'maintainers' and
> 'pull requests' if we wanted to :)
>
> regards,
>
> Koen
+1

G
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Frans Meulenbroeks]

Nice piece of work & a good plan but...

Who will be the owners/maintainers of the layers?
I maintain several multimedia recipes (mythtv with all that is dragged
in (which is a.o. a lot of perl stuff), various cd*  related recipes,
python-coherence and the python stuff it uses, mediatomb, and it seems
recently people seem to see me as the first line of contact if they
have musicpd issues), as well as some file sharing recipes.
Any idea on how I get them added, and how to deal with updates for these?

An alternate approach would be to let the stuff live in poky-extras.
See this proposal from RP:
http://www.mail-archive.com/yocto@yoctoproject.org/msg00286.html

Frans.

PS: personally I would have preferred it if console-image was in the
common part.I guess some other recipes will get fairly identical
recipes.
Maybe we should have a generic console-image and let each distro use
.bbappend or aminc to extend on it.

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Maupin, Chase]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Frans Meulenbroeks
> Sent: Monday, December 20, 2010 11:17 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [RFC] meta-openembedded layer for yocto hosted on oe.org
> 
> Nice piece of work & a good plan but...
> 
> Who will be the owners/maintainers of the layers?
> I maintain several multimedia recipes (mythtv with all that is dragged
> in (which is a.o. a lot of perl stuff), various cd*  related recipes,
> python-coherence and the python stuff it uses, mediatomb, and it seems
> recently people seem to see me as the first line of contact if they
> have musicpd issues), as well as some file sharing recipes.
> Any idea on how I get them added, and how to deal with updates for these?
> 
> An alternate approach would be to let the stuff live in poky-extras.
> See this proposal from RP:
> http://www.mail-archive.com/yocto@yoctoproject.org/msg00286.html

Frans,

What is the difference between poky-extras and angstrom-layers in regards to the intention.  My understanding is that Koen wanted to put the meta-openembedded layer on OE so it would be open to anyone.  Couldn't you then add recipes for the components you maintain into this layer in places like recipes-multimedia?  

Or are you concerned about who would maintain some of the individual recipe groupings like multimedia?  i.e. if recipes-multimedia is part of meta-openembedded are you concerned that you won't be able to push changes to your recipes?  I see your issue here in that you want to maintain your recipes without restriction but at the same time if everyone just puts their recipes into their own layer we would have way too many layers and it would be extremely hard to keep track of.

So would a good solution be to have multiple committers to the meta-openembedded layer (like Koen was suggesting) and let each committer be a maintainer with an emphasis on a particular area (Also seems in line with what Richard was suggesting)?

Perhaps I am misunderstanding the proposal here but it seems like we are really discussing whether we use poky-extras or angstrom-layers, or something with another name.  I would say that we leave angstrom-layers containing the angstrom stuff, make an openembedded layer hosted on OE (like Koen suggested) rather than cramming everything into poky-extras (since poky is just one distribution and there are others).

I guess an alternative suggestion is to have each functional grouping like multimedia be its own layer and then you can have one or more maintainers per layer.  Then you can just group these layers under the OE name (which is basically what Richard was suggesting but calling it poky-extras).

> 
> Frans.
> 
> PS: personally I would have preferred it if console-image was in the
> common part.I guess some other recipes will get fairly identical
> recipes.
> Maybe we should have a generic console-image and let each distro use
> .bbappend or aminc to extend on it.
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Frans Meulenbroeks]

2010/12/20 Maupin, Chase <chase.maupin@ti.com>:
>
>> -----Original Message-----
>> From: openembedded-devel-bounces@lists.openembedded.org
>> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
>> Frans Meulenbroeks
>> Sent: Monday, December 20, 2010 11:17 AM
>> To: openembedded-devel@lists.openembedded.org
>> Subject: Re: [oe] [RFC] meta-openembedded layer for yocto hosted on oe.org
>>
>> Nice piece of work & a good plan but...
>>
>> Who will be the owners/maintainers of the layers?
>> I maintain several multimedia recipes (mythtv with all that is dragged
>> in (which is a.o. a lot of perl stuff), various cd*  related recipes,
>> python-coherence and the python stuff it uses, mediatomb, and it seems
>> recently people seem to see me as the first line of contact if they
>> have musicpd issues), as well as some file sharing recipes.
>> Any idea on how I get them added, and how to deal with updates for these?
>>
>> An alternate approach would be to let the stuff live in poky-extras.
>> See this proposal from RP:
>> http://www.mail-archive.com/yocto@yoctoproject.org/msg00286.html
>
> Frans,
>
> What is the difference between poky-extras and angstrom-layers in regards to the intention.  My understanding is that Koen wanted to put the meta-openembedded layer on OE so it would be open to anyone.  Couldn't you then add recipes for the components you maintain into this layer in places like recipes-multimedia?
>
> Or are you concerned about who would maintain some of the individual recipe groupings like multimedia?  i.e. if recipes-multimedia is part of meta-openembedded are you concerned that you won't be able to push changes to your recipes?  I see your issue here in that you want to maintain your recipes without restriction but at the same time if everyone just puts their recipes into their own layer we would have way too many layers and it would be extremely hard to keep track of.
>
> So would a good solution be to have multiple committers to the meta-openembedded layer (like Koen was suggesting) and let each committer be a maintainer with an emphasis on a particular area (Also seems in line with what Richard was suggesting)?
>
> Perhaps I am misunderstanding the proposal here but it seems like we are really discussing whether we use poky-extras or angstrom-layers, or something with another name.  I would say that we leave angstrom-layers containing the angstrom stuff, make an openembedded layer hosted on OE (like Koen suggested) rather than cramming everything into poky-extras (since poky is just one distribution and there are others).
>
> I guess an alternative suggestion is to have each functional grouping like multimedia be its own layer and then you can have one or more maintainers per layer.  Then you can just group these layers under the OE name (which is basically what Richard was suggesting but calling it poky-extras).
>

Chase, all,

Only a brief reply as I stuck with the flu at the moment (and maybe
that'll make my mails even less coherent than usual :-) )

Koen talks also about pull model and maintainers. Richards direction
seems to be to have layer maintainers (who probably pull changes)
This seems a good plan for the bsp and the distro layers.
But I am not sure that for the oe tree a pull model would be a good
step now, not even on the layer level (that is why I brought the
multimedia example).
Of course we could be fairly open to maintainer for a layer if we
wanted to.In a sense in OE everyone can change everything, and that is
no good either.
I'd love to see some more info on how we propose to deal with that part.

The concern I have of this proposal compared to poky-extras was that
we might see the same same recipe surface at different places, which
does not seem to desirable.

BTW: I am seeing poky as a build system (actually iirc the official
name is platform builder) not as a distro.

Back to my orange juice. Frans

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20-12-10 18:16, Frans Meulenbroeks wrote:
> Nice piece of work & a good plan but...
> 
> Who will be the owners/maintainers of the layers?

My intention was that the meta-openembedded layer will be maintained by
the people interested in it. There will be a new MAINTAINERS file inside
listing who feels responsible for various recipes.

> An alternate approach would be to let the stuff live in poky-extras.
> See this proposal from RP:
> http://www.mail-archive.com/yocto@yoctoproject.org/msg00286.html

The poky-extras thing is not what I want, and more importantly, I don't
want to start diluting the OE brand.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNEGJWMkyGM64RGpERApHaAJ9Nk5bO08BlF40T3LH8S9ymgRFsvwCdGeQ3
WREzWeCb8t1INOGEfxILgTM=
=3PyE
-----END PGP SIGNATURE-----

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Khem Raj]

On Mon, Dec 20, 2010 at 7:53 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I've locally split
> http://gitorious.org/angstrom/angstrom-layers/commits/master into 3
> seperate git repos with git-filter-branch. I would like to move the
> meta-openembedded layer to the OE git server to make it easier for
> others to help in cleaning it up and getting more use to layers. The
> beagle and angstrom layers could move there as well, but those will need
> a more restricted set of committers.
>
> In essence I would like this to be the "official" OE layer for yocto
> while the board is dealing with the yocto negotiations.
>

yes this is something what we should do. We need to setup gitolite on
the git server
first which will give us finer control on access types. Cliff has been
working on it.


> This would be a good chance to try out things like 'maintainers' and
> 'pull requests' if we wanted to :)
>

yes this would be the intended model thereafter.

> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFND3wGMkyGM64RGpERAspRAKCQS+ZtZqw/my9oTZ8l+O4KqD+WDQCcDeij
> 7XzhyxcmFBpGtwWwGZC7QT0=
> =EH9g
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Cliff Brake]

On Mon, Dec 20, 2010 at 10:53 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> I've locally split
> http://gitorious.org/angstrom/angstrom-layers/commits/master into 3
> seperate git repos with git-filter-branch. I would like to move the
> meta-openembedded layer to the OE git server to make it easier for
> others to help in cleaning it up and getting more use to layers.

git@git.openembedded.org:meta-openembedded is now available.  Note,
someone will need to push something to it before it exists.

Thanks,
Cliff

-- 
=================
http://bec-systems.com

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 21-12-10 16:43, Cliff Brake wrote:
> On Mon, Dec 20, 2010 at 10:53 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>> I've locally split
>> http://gitorious.org/angstrom/angstrom-layers/commits/master into 3
>> seperate git repos with git-filter-branch. I would like to move the
>> meta-openembedded layer to the OE git server to make it easier for
>> others to help in cleaning it up and getting more use to layers.
> 
> git@git.openembedded.org:meta-openembedded is now available.  Note,
> someone will need to push something to it before it exists.

And here it is: http://cgit.openembedded.org/cgit.cgi/meta-openembedded/

Thanks Cliff & Tom!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNENToMkyGM64RGpERAmZfAJ95GWNvBXjmvu7YvETrkXtP8Pa9vQCeOWUv
VN2bymFBMFiTNiScPR52kWI=
=xhQy
-----END PGP SIGNATURE-----

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Frans Meulenbroeks]

2010/12/21 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 20-12-10 18:16, Frans Meulenbroeks wrote:
>> Nice piece of work & a good plan but...
>>
>> Who will be the owners/maintainers of the layers?
>
> My intention was that the meta-openembedded layer will be maintained by
> the people interested in it. There will be a new MAINTAINERS file inside
> listing who feels responsible for various recipes.

Ah ok.
Seems a good plan.
>
>> An alternate approach would be to let the stuff live in poky-extras.
>> See this proposal from RP:
>> http://www.mail-archive.com/yocto@yoctoproject.org/msg00286.html
>
> The poky-extras thing is not what I want, and more importantly, I don't
> want to start diluting the OE brand.

Why wouldn't you want poky-extras?
My concern is that we get lots of duplicated effort because both
poky-extras and meta-openembedded might get the same recipes.
Maybe this should be one of the items to be discussed with the yocto
board (and maybe come to one user contributed layer).

BTW it seems good to come up with some guidelines on the
meta-openembedded layer (or maybe usage rules or so).
E.g. personally I would expect that if I put meta-openembedded on top
of e.g. poky/laverne that a recipe in it builds).
So no dependencies on non poky recipes. Is that an agreed assumption?

Wrt diluting the OE brand. This is a completely different topic.
IMHO the mere fact that yocto exists impacts OE.
Yocto also has much more resources (both people-hour wise as well as
HW wise), so I strongly doubt we can compete on it wrt the quality of
the base recipes.

That leaves the question:
Given the existence of Yocto in which parts do we see added value of
OE and on which things should we as OE focus.
But I guess this is more something for a different thread.

Frans

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Khem Raj]

On Tue, Dec 21, 2010 at 9:51 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/12/21 Koen Kooi <k.kooi@student.utwente.nl>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 20-12-10 18:16, Frans Meulenbroeks wrote:
>>> Nice piece of work & a good plan but...
>>>
>>> Who will be the owners/maintainers of the layers?
>>
>> My intention was that the meta-openembedded layer will be maintained by
>> the people interested in it. There will be a new MAINTAINERS file inside
>> listing who feels responsible for various recipes.
>
> Ah ok.
> Seems a good plan.
>>
>>> An alternate approach would be to let the stuff live in poky-extras.
>>> See this proposal from RP:
>>> http://www.mail-archive.com/yocto@yoctoproject.org/msg00286.html
>>
>> The poky-extras thing is not what I want, and more importantly, I don't
>> want to start diluting the OE brand.
>
> Why wouldn't you want poky-extras?
> My concern is that we get lots of duplicated effort because both
> poky-extras and meta-openembedded might get the same recipes.
> Maybe this should be one of the items to be discussed with the yocto
> board (and maybe come to one user contributed layer).
>

duplication of recipes can occur within layers and will happen
deliberately too no matter where the layer is hosted. If someone wants
to override
the default provided layer. its a OE layer so hosting it on OE infra
is logical thing as most of OE users
will look it up here.

> BTW it seems good to come up with some guidelines on the
> meta-openembedded layer (or maybe usage rules or so).
> E.g. personally I would expect that if I put meta-openembedded on top
> of e.g. poky/laverne that a recipe in it builds).
> So no dependencies on non poky recipes. Is that an agreed assumption?
>
> Wrt diluting the OE brand. This is a completely different topic.
> IMHO the mere fact that yocto exists impacts OE.

It impacts but in a good way.

> Yocto also has much more resources (both people-hour wise as well as
> HW wise), so I strongly doubt we can compete on it wrt the quality of
> the base recipes.
>

you take is wrongly I think. I think its a good thing for
openemebedded as an architecture

> That leaves the question:
> Given the existence of Yocto in which parts do we see added value of
> OE and on which things should we as OE focus.

there is more closer collaboration needed on day to day bases to get
it to work seemlessly together.
You just cant say OE should focus on xyz only as yocto has
openembedded at its core.

> But I guess this is more something for a different thread.
>
> Frans
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Tom Rini]

On 12/21/2010 02:45 AM, Khem Raj wrote:
> On Mon, Dec 20, 2010 at 7:53 AM, Koen Kooi<k.kooi@student.utwente.nl>  wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> I've locally split
>> http://gitorious.org/angstrom/angstrom-layers/commits/master into 3
>> seperate git repos with git-filter-branch. I would like to move the
>> meta-openembedded layer to the OE git server to make it easier for
>> others to help in cleaning it up and getting more use to layers. The
>> beagle and angstrom layers could move there as well, but those will need
>> a more restricted set of committers.
>>
>> In essence I would like this to be the "official" OE layer for yocto
>> while the board is dealing with the yocto negotiations.
>>
>
> yes this is something what we should do. We need to setup gitolite on
> the git server

Can I just put in my 2 cents for some github love?  Chris got me started 
using it and I'm quite happy.  It'd also be less admin work and since I 
forked Chris' tree, my space usage is still practically nil (I'm not 
sure about his), so the free accounts are fine.

-- 
Tom Rini
Mentor Graphics Corporation

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Cliff Brake]

On Tue, Dec 21, 2010 at 1:48 PM, Tom Rini <tom_rini@mentor.com> wrote:

>> yes this is something what we should do. We need to setup gitolite on
>> the git server
>
> Can I just put in my 2 cents for some github love?  Chris got me started
> using it and I'm quite happy.  It'd also be less admin work and since I
> forked Chris' tree, my space usage is still practically nil (I'm not sure
> about his), so the free accounts are fine.

I'm sure our gitserver will never compare to github in features, but
it seems like there is a fundamental limit in that github cannot
possible host every git repo on the planet, especially for larger
projects like OE where you have a lot of people pulling.  I think
there is some value in:

1) hosting OE at openembedded.org (branding, professional image, etc).
 That said, I realize that companies like Nokia are hosting their
stuff on gitorious (http://qt.gitorious.org/), so perhaps this is not
an issue, though its likely Nokia is funding Gitorious to obtain
bandwidth, etc.
2) we are more in control of bandwidth, locations, etc.  We have a lot
of checkouts from our repo, and other than some problems in Europe, I
think our availability has been reasonably good.

I don't know if these benefits outweigh those provided by github.
Perhaps some others can share experiences.

Cliff

-- 
=================
http://bec-systems.com

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Marcin Juszkiewicz]

[-- Attachment #1: Type: Text/Plain, Size: 3600 bytes --]

Dnia wtorek, 21 grudnia 2010 o 18:51:25 Frans Meulenbroeks napisał(a):
> 2010/12/21 Koen Kooi <k.kooi@student.utwente.nl>:
> >> Nice piece of work & a good plan but...
> >> Who will be the owners/maintainers of the layers?
> > 
> > My intention was that the meta-openembedded layer will be maintained by
> > the people interested in it. There will be a new MAINTAINERS file inside
> > listing who feels responsible for various recipes.

> Seems a good plan.

I just gave on irc how I see cooperation with Yocto:

- yocto-core layer - maintained by Yocto, builds always for selected targets,
  pull only way of providing changes - just like Poky was
- oe-core layer - extra images, classes required by OE builds. Same policies 
  as Yocto core - only pull from user branches if changes pass test builds
- oe-distro-DISTRO (for those distros which needs own layers - like angstrom
  does) maintained by distro maintainers with their policies
- oe-bsp-STH maintained by layer maintainers with their policies
- oe-extra-STH (STH = opie, xfce, whatever) maintained by person/team
- oe-unmaintained layer with everything not fit in layers

This way we can get stable core (yocto-core + oe-core) which builds always for 
selected targets + layers with UI environments, multimedia, boards/soc 
support, etc each of them maintained by person or team. How we will split 
metadata into layers (and subdirs in layers) is other thing and will need to 
be discussed too.

> >> An alternate approach would be to let the stuff live in poky-extras.
> >> See this proposal from RP:
> >> http://www.mail-archive.com/yocto@yoctoproject.org/msg00286.html
> > 
> > The poky-extras thing is not what I want, and more importantly, I don't
> > want to start diluting the OE brand.
> 
> Why wouldn't you want poky-extras?
> My concern is that we get lots of duplicated effort because both
> poky-extras and meta-openembedded might get the same recipes.

Poky-extras is part of Poky not OpenEmbedded. Our brand has 7 years and we do 
not want to let it disappear. This will send wrong message to people who use 
our work.
 
> Wrt diluting the OE brand. This is a completely different topic.
> IMHO the mere fact that yocto exists impacts OE.
> Yocto also has much more resources (both people-hour wise as well as
> HW wise), so I strongly doubt we can compete on it wrt the quality of
> the base recipes.

Thats why we should move to use Yocto as base. We have skilled developers too 
which can and will provide changes to yocto-core layer. But those changes will 
require testing before being merged which can be new thing for some of OE 
developers ;)
 
> That leaves the question:
> Given the existence of Yocto in which parts do we see added value of
> OE and on which things should we as OE focus.

OE supports more targets then Yocto does or will ever support. I do not expect 
Yocto to support Intel Mainstone or Simpad or even Alix.1c which I use for my 
router. But OE supports those machines (more or less) and this is our value. 
There are boards outside which boots to OpenEmbedded derived root filesystems 
- not Yocto or Poky but OE based.

If we do proper separation of layers then who knows - maybe some vendors which 
base on OE will start to base on Yocto directly. But as OE will also base on 
Yocto then it will be not a problem to use vendor layers with our ones to 
provide extra packages.

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Chris Larson]

On Tue, Dec 21, 2010 at 12:25 PM, Cliff Brake <cliff.brake@gmail.com> wrote:
> On Tue, Dec 21, 2010 at 1:48 PM, Tom Rini <tom_rini@mentor.com> wrote:
>
>>> yes this is something what we should do. We need to setup gitolite on
>>> the git server
>>
>> Can I just put in my 2 cents for some github love?  Chris got me started
>> using it and I'm quite happy.  It'd also be less admin work and since I
>> forked Chris' tree, my space usage is still practically nil (I'm not sure
>> about his), so the free accounts are fine.
>
> I'm sure our gitserver will never compare to github in features, but
> it seems like there is a fundamental limit in that github cannot
> possible host every git repo on the planet, especially for larger
> projects like OE where you have a lot of people pulling.  I think
> there is some value in:

Like Tom says, each user has a limit of what they can store with a
free account.  Any single git repository doesn't take much space.
When someone wants to do some personal work, they fork the upstream
repo into theirs (so they now have a single copy of the oe repository
in their account), and they work there.  I don't think space is much
of a concern.  The other points, about branding, etc are valid.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Denys Dmytriyenko]

On Tue, Dec 21, 2010 at 05:25:13PM +0100, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 21-12-10 16:43, Cliff Brake wrote:
> > On Mon, Dec 20, 2010 at 10:53 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> >> I've locally split
> >> http://gitorious.org/angstrom/angstrom-layers/commits/master into 3
> >> seperate git repos with git-filter-branch. I would like to move the
> >> meta-openembedded layer to the OE git server to make it easier for
> >> others to help in cleaning it up and getting more use to layers.
> > 
> > git@git.openembedded.org:meta-openembedded is now available.  Note,
> > someone will need to push something to it before it exists.
> 
> And here it is: http://cgit.openembedded.org/cgit.cgi/meta-openembedded/
> 
> Thanks Cliff & Tom!

Thanks Koen et al. for starting the work!

-- 
Denys

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Frans Meulenbroeks]

Marcin, thanks for the good post!

2010/12/21 Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>:
> Dnia wtorek, 21 grudnia 2010 o 18:51:25 Frans Meulenbroeks napisał(a):
>> 2010/12/21 Koen Kooi <k.kooi@student.utwente.nl>:
>> >> Nice piece of work & a good plan but...
>> >> Who will be the owners/maintainers of the layers?
>> >
>> > My intention was that the meta-openembedded layer will be maintained by
>> > the people interested in it. There will be a new MAINTAINERS file inside
>> > listing who feels responsible for various recipes.
>
>> Seems a good plan.
>
> I just gave on irc how I see cooperation with Yocto:
>
> - yocto-core layer - maintained by Yocto, builds always for selected targets,
>  pull only way of providing changes - just like Poky was
> - oe-core layer - extra images, classes required by OE builds. Same policies

Good plan.
I guess we need to decide on the procedure for something to get in.
I would propose that we maintain a version policy similar to yocto (if
I recall correctly what RP wrote about it, it was e.g. preferably only
one version of a recipe and keeping a fairly close tracking of new
versions, forgot the other wise words he said on the topic).
The key probem to me seems to be how to deal with new versions of e.g.
libs. Toolchain changed will probably be driven by yocto.
And ofc we need a volunteer (or some) to pull, verify that it works etc)

>  as Yocto core - only pull from user branches if changes pass test builds
> - oe-distro-DISTRO (for those distros which needs own layers - like angstrom
>  does) maintained by distro maintainers with their policies
> - oe-bsp-STH maintained by layer maintainers with their policies
> - oe-extra-STH (STH = opie, xfce, whatever) maintained by person/team
> - oe-unmaintained layer with everything not fit in layers

Seems a nice split to me.
>
> This way we can get stable core (yocto-core + oe-core) which builds always for
> selected targets + layers with UI environments, multimedia, boards/soc
> support, etc each of them maintained by person or team. How we will split
> metadata into layers (and subdirs in layers) is other thing and will need to
> be discussed too.

I can also imagine testing comes around the corner here.
E.g. the OE-core maintainer pulls/picks changes, gives it a testing
tag then some people fire off testing builds, if these are all ok, the
changes get promoted.
But ofc we can also think about other scenarios.
(or maybe instead of testing we have a core-next layer that is
promoted to core once testing is succesful.

>
>> >> An alternate approach would be to let the stuff live in poky-extras.
>> >> See this proposal from RP:
>> >> http://www.mail-archive.com/yocto@yoctoproject.org/msg00286.html
>> >
>> > The poky-extras thing is not what I want, and more importantly, I don't
>> > want to start diluting the OE brand.
>>
>> Why wouldn't you want poky-extras?
>> My concern is that we get lots of duplicated effort because both
>> poky-extras and meta-openembedded might get the same recipes.
>
> Poky-extras is part of Poky not OpenEmbedded. Our brand has 7 years and we do
> not want to let it disappear. This will send wrong message to people who use
> our work.

I agree on that.But it must be clear what our added value is.

>
>> Wrt diluting the OE brand. This is a completely different topic.
>> IMHO the mere fact that yocto exists impacts OE.
>> Yocto also has much more resources (both people-hour wise as well as
>> HW wise), so I strongly doubt we can compete on it wrt the quality of
>> the base recipes.
>
> Thats why we should move to use Yocto as base. We have skilled developers too
> which can and will provide changes to yocto-core layer. But those changes will
> require testing before being merged which can be new thing for some of OE
> developers ;)

Agree.
>
>> That leaves the question:
>> Given the existence of Yocto in which parts do we see added value of
>> OE and on which things should we as OE focus.
>
> OE supports more targets then Yocto does or will ever support. I do not expect
> Yocto to support Intel Mainstone or Simpad or even Alix.1c which I use for my
> router. But OE supports those machines (more or less) and this is our value.
> There are boards outside which boots to OpenEmbedded derived root filesystems
> - not Yocto or Poky but OE based.

I agree. Actually I have a few of these boards myself.
But we're more than a bunch of BSP layers. (I don't think we disagree
on this :-) )
>
> If we do proper separation of layers then who knows - maybe some vendors which
> base on OE will start to base on Yocto directly. But as OE will also base on
> Yocto then it will be not a problem to use vendor layers with our ones to
> provide extra packages.

Sure. I might even work for such a company!

Frans

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Esben Haabendal]

On Tue, 2010-12-21 at 18:51 +0100, Frans Meulenbroeks wrote:

> That leaves the question:
> Given the existence of Yocto in which parts do we see added value of
> OE and on which things should we as OE focus.
> But I guess this is more something for a different thread.

With or without Yocto, it seems like a good question to ask what we
would like to see improved in OE, ie. what would we like to see go into
OE within the next 1-2 years.

With that in mind, it should be somewhat easier to find out how to guide
OE community directions with relation to Yocto project.

I personally have the feeling that Yocto project have been given the
man-power to brute-force improve the quality of Poky/OpenEmbedded on a
day-by-day basis, and I expect they will be doing a good job at that.

One attractive direction of OE development would in my opinion to look a
bit further into the future, and work on fundamental improvements on
selected focus areas.

I imagine that Yocto will be expected to deliver continuous stream of
improvements to Poky, and will in practise be restricted to development
in microsteps of improvements.  Any improvements to OE that will require
a break in this continous stream is therefore something that OE might be
able to add value compared to what Yocto will deliver.

Of-course, I might just be beating a dead horse...

/Esben

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20-12-10 16:53, Koen Kooi wrote:
> Hi,
> 
> I've locally split
> http://gitorious.org/angstrom/angstrom-layers/commits/master into 3
> seperate git repos with git-filter-branch. I would like to move the
> meta-openembedded layer to the OE git server to make it easier for
> others to help in cleaning it up and getting more use to layers. The
> beagle and angstrom layers could move there as well, but those will need
> a more restricted set of committers.
> 
> In essence I would like this to be the "official" OE layer for yocto
> while the board is dealing with the yocto negotiations.

Now that the repo is out there and writable for every OE committer (if I
didn't mess up gitolite), the easiest way to get started is to use this
script:

http://gitorious.org/angstrom/angstrom-setup-scripts/commits/yoctoproject

That will pull all the needed git repositories and assemble a bblayers.conf.

As being discussed on the oe-members list, we desperately need a
workable solution to deal with multiple git repos for layers. Personally
I like Michaels approach of using a flat config file with a git uri for
each layer, but I'm open to other solutions.

I'm now going to read up on license checksumming, RP is going to enable
the killswitch in yocto soon.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNEd6sMkyGM64RGpERAoQSAKCJKYLKnbG+yKGISQgtEhmW5h8ulwCfaC5F
d0zqL9aaDRM6nnGLKFLsYOU=
=7ovB
-----END PGP SIGNATURE-----

Re: [RFC] meta-openembedded layer for yocto hosted on oe.org

[Frans Meulenbroeks]

There hasn't been too much discussion on Marcin's proposal below
(maybe lots of people enjoyed a good Xmas holiday!)

I still feel Marcin's proposal is a good plan.
Do we want to move this way?

If so, what about some action?

Frans


2010/12/21 Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>:
> Dnia wtorek, 21 grudnia 2010 o 18:51:25 Frans Meulenbroeks napisał(a):
>> 2010/12/21 Koen Kooi <k.kooi@student.utwente.nl>:
>> >> Nice piece of work & a good plan but...
>> >> Who will be the owners/maintainers of the layers?
>> >
>> > My intention was that the meta-openembedded layer will be maintained by
>> > the people interested in it. There will be a new MAINTAINERS file inside
>> > listing who feels responsible for various recipes.
>
>> Seems a good plan.
>
> I just gave on irc how I see cooperation with Yocto:
>
> - yocto-core layer - maintained by Yocto, builds always for selected targets,
>  pull only way of providing changes - just like Poky was
> - oe-core layer - extra images, classes required by OE builds. Same policies
>  as Yocto core - only pull from user branches if changes pass test builds
> - oe-distro-DISTRO (for those distros which needs own layers - like angstrom
>  does) maintained by distro maintainers with their policies
> - oe-bsp-STH maintained by layer maintainers with their policies
> - oe-extra-STH (STH = opie, xfce, whatever) maintained by person/team
> - oe-unmaintained layer with everything not fit in layers
>
> This way we can get stable core (yocto-core + oe-core) which builds always for
> selected targets + layers with UI environments, multimedia, boards/soc
> support, etc each of them maintained by person or team. How we will split
> metadata into layers (and subdirs in layers) is other thing and will need to
> be discussed too.
>
>> >> An alternate approach would be to let the stuff live in poky-extras.
>> >> See this proposal from RP:
>> >> http://www.mail-archive.com/yocto@yoctoproject.org/msg00286.html
>> >
>> > The poky-extras thing is not what I want, and more importantly, I don't
>> > want to start diluting the OE brand.
>>
>> Why wouldn't you want poky-extras?
>> My concern is that we get lots of duplicated effort because both
>> poky-extras and meta-openembedded might get the same recipes.
>
> Poky-extras is part of Poky not OpenEmbedded. Our brand has 7 years and we do
> not want to let it disappear. This will send wrong message to people who use
> our work.
>
>> Wrt diluting the OE brand. This is a completely different topic.
>> IMHO the mere fact that yocto exists impacts OE.
>> Yocto also has much more resources (both people-hour wise as well as
>> HW wise), so I strongly doubt we can compete on it wrt the quality of
>> the base recipes.
>
> Thats why we should move to use Yocto as base. We have skilled developers too
> which can and will provide changes to yocto-core layer. But those changes will
> require testing before being merged which can be new thing for some of OE
> developers ;)
>
>> That leaves the question:
>> Given the existence of Yocto in which parts do we see added value of
>> OE and on which things should we as OE focus.
>
> OE supports more targets then Yocto does or will ever support. I do not expect
> Yocto to support Intel Mainstone or Simpad or even Alix.1c which I use for my
> router. But OE supports those machines (more or less) and this is our value.
> There are boards outside which boots to OpenEmbedded derived root filesystems
> - not Yocto or Poky but OE based.
>
> If we do proper separation of layers then who knows - maybe some vendors which
> base on OE will start to base on Yocto directly. But as OE will also base on
> Yocto then it will be not a problem to use vendor layers with our ones to
> provide extra packages.
>
> Regards,
> --
> JID:      hrw@jabber.org
> Website:  http://marcin.juszkiewicz.com.pl/
> LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>