[oe] Yocto Project and OE - Where now?

[Frans Meulenbroeks]

2011/1/19 Mike Westerhof <mike at mwester.net>:
> 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?

I hope the latter, but this is not fully ironed out.

>
> - Does this not "silo" things even more?  For example, I have found life
> has gotten much easier now that other autobuilders are building SlugOS

You're welcome! Glad you like it (that reminds me that I still have to
add last weeks result to the table)

> -- 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?

My impression would be that the slugos layer would only contain the
slugos distro specific stuff.
E.g. things like conf/distro/slugos.conf and what is included by it,
and slugos specific recipes (probably things like upslug2, although
technically they are nslu2 specific not slugos specific, so they could
also go into an nslu2 machine layer).
But this has not really been discussed as far as i recall.
>
> - 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).

I hope not. Actually as OE-core has also the yocto momentum behind it
I guess that forks will probably die because the additional effort is
not available or does not pay off well.
Preferably we should keep it one repo.
Having a good maintainer/integrator also helps (with authority and
good judgement).
The process for OE-core would probably be similar to what u-boot and
the kernel do.
>
>  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).

This is definitely  an issue we need to address.
>
>  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?

I'd hope there is lots of sharing and little effort needed to create a
new layer.

>
>
> I'm putting on my asbestos skivvies, since I expect this must have
> already been discussed :)

:-)

Enjoy, Frans.