Re: Yocto Project and OE - Where now?

[Khem Raj <raj.khem@gmail.com>]

On Wed, Jan 19, 2011 at 7:09 AM, Mike Westerhof <mike@mwester.net> wrote:
> As I read this thread, I find that as a distro maintainer, I'm a bit
> unclear on a few points.  Pardon me if I've just failed to read/follow
> this thread...
>
> - So if I wish (or am forced) to use "layers", where do they come from?
>  Am I then responsible for finding a git hosting service, arranging for
> CIA commit messages, etc?  Or will each layer be hosted alongside the
> main OE repo?  Or have we not yet considered the added administrative
> burden of multiple repos?

well if distro is kept in sync with oe-core it should not need many bits.
may be oe-meta will hold all the remaining bits that it might need on top

>
> - Does this not "silo" things even more?  For example, I have found life
> has gotten much easier now that other autobuilders are building SlugOS
> -- but what incentive do people have if they have to deal with adding
> layers and all that, especially if the "SlugOS layer" ends up with a
> conflict in some fashion with the "Angstrom layer"?  And
> correspondingly, if I am struggling with some issue, would it not be
> less likely that I could get assistance and guidance from #OE if I'm
> using some layer?

yes we are learning about layers and certainly there will be issues
there is priority so if you want to override over angstrom-layer you can
and still use angstrom-layer. I think if we do a good job of oe-core then
the possibility of conflicts could be minimised.

>
> - And unless I'm not missing something with the layers proposal (and I
> hope I am), is it not most likely that we'll end up with the following
> scenario:
>
>  a) Larger distros eventually fork OE-core and go off on their own as
> they find that their "layer" becomes more and more substantial compared
> to OE-core, especially when "people-originated conflicts" occur rather
> than "technically-originated conflicts" (a single repo tends to force
> resolution of the former).

if we do a lousy work in maintaining oe-core chances of this happening are less
IOW we have to keep the distros in mind when we work on oe-core and cater
to their needs absolutely in a portable way

>
>  b) Small distros are forced to comply with nothing but OE-core, or
> perish -- the cost of maintaining the extra infrastructure (git, cgit,
> CIA, etc, etc) along with the added complexity of teaching new distro
> developers about this new layer of stuff) is simply too high, not to
> mention that creating a layer for distro-specific stuff might be an
> instant killer in terms of autobuilder and assistance from the OE
> community at large (I ask myself -- do *I* intend to pull the Angstrom
> layer and build it?  I've done so in the past, but only because it was
> trivial to kick off such a build... but with layers, it seems it will be
> far harder to do so -- unless I'm missing something).
>

The meta-oe layer will host I think all bits out of oe-core

>  c) Obscure/experimental distros simply die off, or find an alternative
> to OE.  The learning curve is quite steep already, and without access to
> shared knowledge, shared recipes, and the assistance of the community,
> what is there to encourage a newcomer to use OE?

well its just that you will have two or more repos to pull from to
make what you get in one shot
from OE as of today
>
>
> I'm putting on my asbestos skivvies, since I expect this must have
> already been discussed :)
>
> -Mike (mwester)
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>