Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Esben Haabendal <eha@dev.doredevelopment.dk>
Cc: poky <poky@yoctoproject.org>,
	Patches, layer <openembedded-core@lists.openembedded.org>
Subject: Re: [poky] Proposed Multilib Implementation Brainstorming
Date: Wed, 06 Apr 2011 07:19:49 -0700	[thread overview]
Message-ID: <1302099589.22904.63.camel@rex> (raw)
In-Reply-To: <87lizn4is9.fsf@eha.doredevelopment.dk>

On Wed, 2011-04-06 at 15:21 +0200, Esben Haabendal wrote:
> Richard Purdie <richard.purdie@linuxfoundation.org> writes:
> 
> > On Wed, 2011-04-06 at 14:16 +0200, Esben Haabendal wrote:
> > I actually believe the core in OE is well suited to multilib support and
> > using it will show off some of the power in the OE architecture as I
> > think we can do it better than anyone else before!
> 
> The one thing that in my experience pushes most people in other
> directiosn than OE is the complexity.  Unless OE made simpler, I think
> it will be quite hard to reach the goal of significantly reducing the
> number of build systems.
>
> I am uncertain to what effect multilib in OE will have (positive and
> negative), but it is clearly not making OE simpler.
>
> I just kind of makes things a bit ehmm... hopeless that the requests I
> (and others with similar customers) hear from companies are considered
> out of line for OE evolution, whereas the requests you and others hear
> can be used as valid arguments for which directions to take.
> 
> It is not that I think it will add considerable burden, but is just yet
> another brick to the wall to pass for developers trying to understand
> OE.

Nobody is saying requests for simplicity or ease of use are out of line,
far from it. Its something that is being worked on by Yocto quite
heavily. What does differ is the approach though, yours is to rip out
anything you personally don't need, Yocto is taking a more reasoned
approach to this and asking questions like:

"What can we do to make things easier for new users?"
"Can we make error messages more user friendly?"
"What code do we have that is needlessly complex and can be simplified?"
"If we are going to add a new feature, how was we reuse existing
established concepts?"
"If something is complex and hard to understand but required, how can we
document or better explain the concepts to people?"

I'd go as far as to say that things are getting more understandable and
easier too. Yocto ran an alpha test programme where we took a selection
of people, some with experience and some with no experience of
embeddded, pointed them at the quick start guide and asked them to build
an image, boot it and experiment. The results of this programme with
Yocto 1.0 are orders of magnitude better than 0.9. This at least shows
the new user experience is better than it was. Its not the only area
that needs improvement and there is a long way to go but its a very
positive start IMO.

Cheers,

Richard




  reply	other threads:[~2011-04-06 14:22 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 11:02 Proposed Multilib Implementation Brainstorming Richard Purdie
2011-04-05 23:28 ` Jeremy Puhlman
2011-04-06 18:53   ` Richard Purdie
2011-04-06  7:08 ` Esben Haabendal
2011-04-06 12:05   ` [poky] " Richard Purdie
2011-04-06 12:16     ` Esben Haabendal
2011-04-06 13:06       ` Richard Purdie
2011-04-06 13:21         ` Esben Haabendal
2011-04-06 14:19           ` Richard Purdie [this message]
2011-04-06 16:38             ` Esben Haabendal
2011-04-06 18:01     ` Hatle, Mark
2011-04-06 20:54       ` Esben Haabendal
2011-04-06 20:55       ` Esben Haabendal
2011-04-06  7:16 ` Koen Kooi
2011-04-06  8:47 ` Frans Meulenbroeks
2011-04-06 14:29   ` Richard Purdie
2011-04-06 18:06     ` [poky] " Hatle, Mark
2011-04-06 18:25   ` Tom Rini
2011-04-07  6:10     ` Koen Kooi
2011-04-06 18:26 ` Hatle, Mark
2011-04-06 18:39   ` Tom Rini
2011-04-07 15:36 ` [poky] " Colin Walters
2011-04-07 16:10   ` Hatle, Mark
2011-04-07 16:53     ` Colin Walters
2011-04-07 17:04       ` Hatle, Mark
2011-04-07 17:10         ` Hatle, Mark
2011-04-07 17:07       ` Koen Kooi

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=1302099589.22904.63.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=eha@dev.doredevelopment.dk \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=poky@yoctoproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox