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

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Mon Dec 20 20:31:47 UTC 2010


2010/12/20 Maupin, Chase <chase.maupin at ti.com>:
>
>> -----Original Message-----
>> From: openembedded-devel-bounces at lists.openembedded.org
>> [mailto:openembedded-devel-bounces at lists.openembedded.org] On Behalf Of
>> Frans Meulenbroeks
>> Sent: Monday, December 20, 2010 11:17 AM
>> To: openembedded-devel at 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




More information about the Openembedded-devel mailing list