Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 4/5] libc-headers: set TC default to 3.14
Date: Mon, 31 Mar 2014 15:50:21 -0400	[thread overview]
Message-ID: <5339C6FD.1070506@windriver.com> (raw)
In-Reply-To: <CAMKF1srfDpeGkQMnHkK_AFPy6N7pujtLwMRsgbsDeHem82_5nA@mail.gmail.com>

On 14-03-31 03:47 PM, Khem Raj wrote:
> -Khem
> On Mar 31, 2014 12:33 PM, "Bruce Ashfield" <bruce.ashfield@windriver.com
> <mailto:bruce.ashfield@windriver.com>> wrote:
>  >
>  > On 14-03-31 03:29 PM, Khem Raj wrote:
>  >>
>  >> On Mon, Mar 31, 2014 at 10:56 AM, Bruce Ashfield
>  >> <bruce.ashfield@windriver.com <mailto:bruce.ashfield@windriver.com>>
> wrote:
>  >>>
>  >>>
>  >>> -LINUXLIBCVERSION ?= "3.10"
>  >>> +LINUXLIBCVERSION ?= "3.14"
>  >>
>  >>
>  >> Does this  buy us much ? Infact its too late to change usespace APIs
>  >
>  >
>  > This was always the plan. I've been building with all the 3.14 -rc
>  > headers for ages .. and as we've talked about in the past, we always
>  > will update them to the newest kernel in any release.
>
> well i think its good to update them however may be some components
> should be given enough soak time and kernel headers are one of such
> pieces since its effects are across layers and they will start testing
> them now.

To be fair, we've had the -dev kernel and headers available for
over a month now.

This is also my second send of this series, so it isn't like this
hasn't been available or broadcast.

People noticing it now, or being busy, isn't something I can directly
control.

>  >
>  > They are compatible with 3.10, and I've tested the combinations of
>  > old kernels, new libc and new kernels with the new libc interfaces.
>
> i dont believe you tested all layer combinations

I've tested everything I can, as has the autobuilder. I can't offer
any more than this.

>  >
>  >
>  >> at this point. 3.10 being LTS
>  >> I would assume its a better option to keep at 3.10
>  >
>  >
>  > I disagree, this is consistent with other releases and the documented
>  > plan of action. I'd rather not have a massive version jump in the fall.
>
> its probably not a bad option to stick to LTS version for kernel headers
> after all

Again, I disagree.

We can maybe keep the 3.10 recipe around, but the default should
be 3.14, we need a matched kernel and libc-headers to get the best 
integration
and leveraging of the latest features.

If we pull the headers, pull the kernel.

Bruce

>  >
>  > Sure 3.14 slipping out by a few weeks upstream was a problem, but its
>  > not like we haven't been testing with it.
>  >
>  > Bruce
>  >
>  >>
>  >
>



  reply	other threads:[~2014-03-31 19:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-31 17:56 [PATCH 0/5] lnux-yocto: 3.14 updates Bruce Ashfield
2014-03-31 17:56 ` [PATCH 1/5] linux-yocto/3.14: introduce versioned recipes Bruce Ashfield
2014-03-31 19:39   ` Paul Barker
2014-03-31 19:41     ` Bruce Ashfield
2014-03-31 17:56 ` [PATCH 2/5] linux-libc-headers: make compression format configurable Bruce Ashfield
2014-03-31 17:56 ` [PATCH 3/5] linux-libc-headers: add 3.14 libc headers Bruce Ashfield
2014-03-31 17:56 ` [PATCH 4/5] libc-headers: set TC default to 3.14 Bruce Ashfield
2014-03-31 19:29   ` Khem Raj
2014-03-31 19:33     ` Bruce Ashfield
2014-03-31 19:47       ` Khem Raj
2014-03-31 19:50         ` Bruce Ashfield [this message]
2014-04-01  6:42           ` Khem Raj
2014-04-01 12:54             ` Bruce Ashfield
2014-04-01 14:50               ` Martin Jansa
2014-04-01 14:52                 ` Bruce Ashfield
2014-04-01 14:54                   ` Richard Purdie
2014-04-01 15:41                     ` Bruce Ashfield
2014-03-31 17:56 ` [PATCH 5/5] linux-libc-headers: remove 3.10 recipe Bruce Ashfield
2014-03-31 21:09 ` [PATCH 0/5] lnux-yocto: 3.14 updates Bruce Ashfield
2014-03-31 22:30   ` Bruce Ashfield

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=5339C6FD.1070506@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    /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