All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Yocto Project and OE - Where now?
Date: Wed, 19 Jan 2011 16:44:35 +0100	[thread overview]
Message-ID: <AANLkTikkZ4dJ=L5x807wLySf=tu=f04LPM6Vf6scdRdX@mail.gmail.com> (raw)
In-Reply-To: <4D36FE98.3070606@mwester.net>

2011/1/19 Mike Westerhof <mike@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.



  reply	other threads:[~2011-01-19 15:45 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-14 17:49 Yocto Project and OE - Where now? Richard Purdie
2011-01-17 15:15 ` Koen Kooi
2011-01-17 19:01 ` Frans Meulenbroeks
2011-01-18  7:21   ` Graeme Gregory
2011-01-18  8:05     ` Otavio Salvador
2011-01-18  8:47       ` Koen Kooi
2011-01-18  9:17         ` Richard Purdie
2011-01-18  9:12       ` Graeme Gregory
2011-01-18 10:15         ` Richard Purdie
2011-01-18 11:05           ` Frans Meulenbroeks
2011-01-18 11:31       ` Mark Brown
2011-01-18 18:45         ` Frans Meulenbroeks
2011-01-18 16:54       ` Tom Rini
2011-01-18 20:12         ` Koen Kooi
2011-01-18 20:48           ` Tom Rini
2011-01-18 22:05             ` Koen Kooi
2011-01-19  8:45               ` Frans Meulenbroeks
2011-01-19  8:58                 ` Graeme Gregory
2011-01-19  9:16                   ` Frans Meulenbroeks
2011-01-19  9:25                 ` Frans Meulenbroeks
2011-01-22 18:16                   ` Tom Rini
2011-01-23 10:11                     ` Frans Meulenbroeks
2011-01-24 17:45                       ` Tom Rini
2011-01-18 22:48             ` Khem Raj
2011-01-19  8:46               ` Frans Meulenbroeks
2011-01-19  8:52                 ` Graeme Gregory
2011-01-19  9:12                   ` Frans Meulenbroeks
2011-01-19  9:19                     ` Graeme Gregory
2011-01-19 11:31                     ` Joshua Lock
2011-01-19 12:44                       ` Frans Meulenbroeks
2011-01-19 15:09                         ` Mike Westerhof
2011-01-19 15:44                           ` Frans Meulenbroeks [this message]
2011-01-19 18:03                           ` Khem Raj
2011-01-19 21:55                             ` C Michael Sundius
2011-01-19 22:01                               ` C Michael Sundius
2011-01-19 22:22                                 ` Philip Balister
2011-01-19 22:23                               ` Khem Raj
2011-01-19 22:46                                 ` C Michael Sundius
2011-01-20 10:20                                 ` Frans Meulenbroeks
2011-01-20 11:04                                   ` Graeme Gregory
2011-01-20 13:16                                     ` Frans Meulenbroeks
2011-01-19 16:56                 ` Khem Raj
2011-01-22 18:20                 ` Tom Rini
2011-01-23  2:05                   ` Otavio Salvador
2011-01-19  7:47           ` Frans Meulenbroeks
2011-01-19  8:16             ` Martin Jansa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTikkZ4dJ=L5x807wLySf=tu=f04LPM6Vf6scdRdX@mail.gmail.com' \
    --to=fransmeulenbroeks@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.