Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Status Update
Date: Tue, 29 Apr 2014 09:49:38 +0100	[thread overview]
Message-ID: <1398761378.16672.363.camel@ted> (raw)

Executive Summary
=================

The -rc4 build of 1.6 was ready for release with some last minute fixes
for the beaglebone issues (thanks!). Its great to finally get that out
there.

I've started merging changes into master. I've put various gcc changes
forward that I've had a few moments to work on. There was also an issue
I found in bitbake which gives about a 7% build speed improvement on our
standard image test and I found some versions of git are rather slow at
operations which should be fast.

I've not travelled to ELC/OEDAM due to being unwell and worn out :(

1.6 Release
===========

I believe this is ready for release. There are a variety of patches
which did not make it in and we will queue those for a point release.
The timing on the point release will depend on the kind of issues we
find in 1.6.

Master
======

I've started merging patches in so this has opened for changes. Of note
so far:

GCC - I did find a few moments to write most of the patches needed to
rework our parts of our gcc recipes and continue to improve the
toolchain which will be valuable as we more forward. The first part of
these has merged. The second part is out there for review and there are
some bugs there I need to fix before it merges (meta-ide-support in
particular). There is a third set of patches I've not cleaned up and
sent out yet which standardise the toolchain hashes.

Bitbake - The task scheduling algorithm has a couple of bugs in it which
I found after noticing some strange behaviour with low numbers of
threads. This was worth a 7% speedup of our benchmark image build test.
Unfortunately it was too late to get that into 1.6 but it may make the
next point release. I also found that git 1.8 is slow for some
operations and we really want to use 1.9+ (worth around 1 minute on
linux-yocto kernel build time). Chris has also found what looks like a
nasty bug in the codeparser cache which is a good thing to find.

ELC/OEDAM
=========

I've not travelled to ELC/OEDAM as planned. I was already worn out with
previous travel and a variety of other things, then I've come down with
a bug which I held off over the weekend but has caught up with me
now :(. The flights and so on don't agree with me at the best of times
and I'd lost my voice before even leaving so I decided to rest instead.
It wouldn't have been fair to potentially spread the bug around either.

Its the first trip I've ever cancelled and I'm sad not to be at OEDAM in
particular but if I had travelled I doubt I would have been in any state
to participate. Sorry if that causes difficulties for anyone.

I'm aiming to write a separate email about where I think we need to
focus with the project going forward.

Given the situation, I'm going to try rest this week and take a bit of a
break from things. This may slow down patch merging and so on.


Cheers,

Richard






             reply	other threads:[~2014-04-29  8:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-29  8:49 Richard Purdie [this message]
2014-04-29 11:29 ` Status Update Richard Purdie
2014-04-29 17:31   ` Otavio Salvador
  -- strict thread matches above, loose matches on Subject: below --
2014-10-03 12:01 Richard Purdie
2014-04-15 18:45 Richard Purdie
2014-04-08 12:25 Richard Purdie
2014-04-01 13:51 Richard Purdie
2014-03-24 11:53 Richard Purdie
2014-03-18 13:09 Richard Purdie
2014-03-10  2:20 Richard Purdie
2014-03-10  2:43 ` Robert Yang
2013-07-01  7:01 Richard Purdie
2013-05-28 17:35 Richard Purdie
2013-05-28 19:34 ` Jack Mitchell
2013-05-07 12:45 Richard Purdie
2013-04-29 20:57 Richard Purdie
2013-03-20 23:45 Richard Purdie

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=1398761378.16672.363.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox