All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Westerhof <mike@mwester.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Yocto Project and OE - Where now?
Date: Wed, 19 Jan 2011 09:09:12 -0600	[thread overview]
Message-ID: <4D36FE98.3070606@mwester.net> (raw)
In-Reply-To: <AANLkTik9-k_euvDGZd+CFfQ9LyxD_7mubpVxPqyEsEVU@mail.gmail.com>

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?

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

- 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).

  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).

  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'm putting on my asbestos skivvies, since I expect this must have
already been discussed :)

-Mike (mwester)



  reply	other threads:[~2011-01-19 15:16 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 [this message]
2011-01-19 15:44                           ` Frans Meulenbroeks
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=4D36FE98.3070606@mwester.net \
    --to=mike@mwester.net \
    --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.