[Yocto-builds] [poky] meta-yocto-bsp changes and 3.14

Hart, Darren darren.hart at intel.com
Fri Mar 28 13:37:22 PDT 2014

On 3/28/14, 12:27, "Bruce Ashfield" <bruce.ashfield at windriver.com> wrote:

>On 14-03-28 03:22 PM, Hart, Darren wrote:
>> On 3/28/14, 12:14, "Bruce Ashfield" <bruce.ashfield at windriver.com>
>>> On 14-03-28 03:12 PM, Denys Dmytriyenko wrote:
>>>> On Fri, Mar 28, 2014 at 03:08:54PM -0400, Bruce Ashfield wrote:
>>>>> On 14-03-28 03:05 PM, Hart, Darren wrote:
>>>>>> On 3/28/14, 11:59, "Bruce Ashfield" <bruce.ashfield at windriver.com>
>>>>>> wrote:
>>>>>>> On 14-03-28 02:57 PM, Hart, Darren wrote:
>>>>>>>> On 3/28/14, 11:38, "Bruce Ashfield" <bruce.ashfield at windriver.com>
>>>>>>>> wrote:
>>>>>>>>> On 14-03-28 02:34 PM, Richard Purdie wrote:
>>>>>>>>>> With regard to beagleboard, whilst the kernel may have support
>>>>>>>>>> for it,
>>>>>>>>>> I'd like to remove it from meta-yocto-bsp.
>>>>>>>>> ok. I had planned to just leave the compatible machine as 3.10
>>>>>>>>> leave
>>>>>>>>> the support there, since there are a few people who contact me
>>>>>>>>> regularly
>>>>>>>>> and poke with the support.
>>>>>>>>> Is there a place we can put them as a "retirement" home ? versus
>>>>>>>>> asking
>>>>>>>>> people to locally restore the support.
>>>>>>>> The retirement home would be the 1.5 stable releases. Yes?
>>>>>>> Nope. That's my point, I have 3.10 changes for the Xm in
>>>>>>> 3.10 that lives in 1.6. We can make it less visible, but I'd like
>>>>>>> configs to follow the latest versions of the tree.
>>>>>> Isn't it just the SRCREV that matters here? Those can always just be
>>>>>> applied to 1.5. RP is only asking to remove the beagle board as a
>>>>>> reference BSP from the meta-yocto-bsp layer, he doesn't care if the
>>>>>> linux-yocto/meta data remains in place.
>>>>> We are talking past each other. I'm asking for the meta-yocto-bsp and
>>>>> machine conf file to be around .. somewhere .. I don't want people
>>>>> to have to scrounge them up and revive them from old releases, or
>>>>> revert commits to make them available.
>>>>> So this is outside of linux-yocto, I'd like a single layer than when
>>>>> added, gives access to the BSPs "as they were" in the 3.10 tree, and
>>>>> I'd like that layer to not be on people's local drives only.
>>>> 3.10 EOL is projected as Sep, 2015 - do you plan to keep
>>>> linux-yocto-3.10
>>>> until then?
>>> That's the plan. I tried to kill 3.4 before it official died and was
>>> reminded that we'd keep LTSI support around a bit longer. I'm sure we
>>> can bend a bit on the dates, but the general feel is correct .. the
>>> will be around for a while yet.
>> Ah, but here's the thing. If someone wants to use an older kernel
>> they can't risk the change from the newer kernel, then they shouldn't be
>> changing the release either. Dropping support in the next release is not
>> the same as dropping support. The 1.5 series is still getting stable
>> updates, and 3.10 lives on there for that BSP. This is the direction I
>> drive internally as well.
>That's not what I said, and not what I meant. I want to keep the support
>in 3.10 AND 1.6 .. you'll note that I've never said 1.5 at any point.
>I just don't want it to be the official "reference" BSP.
>> I'm still not clear on which changes you are getting at that are
>> to beagle board in 1.6 that are not portable to 1.5. For example:
>As I've said before, I'm not going to support 3.10 updates that I'm
>on master on 1.5, since I'll have to prepare commits for multiple
>release branches and test there.
>If a -stable maintainer wants those commits, they are welcome, but
>I have no bandwidth to backport and test.
>I'm saying that it works in 3.10, and it works against 1.6, and that
>is what I want to be available.

Yes, the 1.5 suggestion was mine in response to working with RP on
reducing the BSPs in meta-yocto-bsp to 1 per architecture per the stated
intent of that layer.

However - that's really all the time I can spend on it :-) Not the hill I
want to die on and all that.

Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center

More information about the yocto-builds mailing list