All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: openembedded-members@lists.openembedded.org
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: Yocto Project and OE - Where now?
Date: Tue, 18 Jan 2011 09:17:24 +0000	[thread overview]
Message-ID: <1295342244.14388.17115.camel@rex> (raw)
In-Reply-To: <BF933EAB-DA94-4C5F-BC91-EF2B45B1B657@dominion.thruhere.net>

On Tue, 2011-01-18 at 09:47 +0100, Koen Kooi wrote:
> Op 18 jan 2011, om 09:05 heeft Otavio Salvador het volgende geschreven:
> > Users of old distros ought to use a specific repository and branch.
> > Master ought to be kept clean for 'next distro release'.
> 
> I've been using yocto for a few months and I *&#(@$*$(*$($@#($@ hate
> their 1 version per recipe policy. Every monday I have a working image
> and every wednesday I have to rebuild from scratch and reevaluate
> because various things got removed and "upgraded". And since my distro
> pin file is in a layer, pinnings don't get noticed.
> So instead of "building on top" of the metadata I need to resort to
> "fork" the metadata. And I'm not the only one seeing this problem, the
> yocto autobuilder is almost perputally red :(

You will notice a change in behaviour from Feb 4th as we hit the release
"freeze" for Yocto's next release as per the schedule on the wiki. At
the moment the codebase is in development flux, then we go to the
stabilisation window. There is a well defined schedule for this and
everyone should have known expectations of what is happening.

The autobuilder has been a bit rough I agree. Saul correctly did call
for stabilisation of the known issues, we've done that, hit green builds
and because the freeze is coming and we've still some major work to
merge in, we're continuing to develop. I appreciated Saul's work in that
area.

So you can see that whilst we are making changes, we are also testing
what we're doing and fixing the regressions we can find. If that testing
is missing things that cause people problems, I'd suggest helping us
find new tests that cover them too.

> Having 10 versions is too much, but having 3 (oldstable, stable,
> development) shouldn't be a problem, especially if they use a
> common .inc file.
> 
> Just look at glib-2.0 in yocto. There's only one version, and that's
> 2.27.5, which is a development release (odd minor number). That's not
> what I want to use in a distro I need to support, especially looking
> at the huge API changes going into the 2.27 series.

Hmm, we should not be using an odd minor number gnome release component
I agree. That should not have happened something has gone wrong there.

> Similar thing for QT, I don't want 4.6.x to suddenly disappear and be
> forced to use 4.7.x. I also don't want to move 4.6.x to a distro
> layer, since QT is way too huge to support on your own.
> 
> Or eglibc or gcc or binuils

For components like these, Yocto aims to pick a version and run with
that for a given release. We want to try and stay reasonable current as
long as the version works. For something based on Yocto, it may be that
as the core moves forward, older versions move into layers if they're
still needed.

Yocto isn't going to make everyone happy or do everything right straight
out the box as we're learning. What I do intend to do is not be afraid
to try things differently but listen to the feedback, adapting
accordingly. OpenEmbedded is stagnating by comparison and I don't think
its healthy.

Cheers,

Richard




  reply	other threads:[~2011-01-18  9:18 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 [this message]
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
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=1295342244.14388.17115.camel@rex \
    --to=rpurdie@rpsys.net \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-members@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.