[meta-freescale] Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm

[Eric Nelson]

On 10/02/2013 06:56 AM, Daiane Angolini wrote:
> On 10/02/2013 10:55 AM, Otavio Salvador wrote:
>> On Wed, Oct 2, 2013 at 10:06 AM, Diego <diego.ml at zoho.com> wrote:
>>>> Otavio requested for the community to approve this change since the
>>>> dora
>>>> branch is being finalized in next 2 weeks.  I'll be upstreaming
>>>> patches to
>>>> master-next this week so they can be tested by end of the week.  Please
>>>> reply to this email if you have a concern with integrating 3.10.9-1.0.0
>>>> into the dora branch.
>>>
>>> Hi Lauren.
>>>
>>> I think there's no objection for merge if that won't be the default.
>>>
>>> What would be the kernel state for dora then?
>>> - 3.0.35 with Vivante 4.6.9p12 patches as default
>>> - 3.5.7 alpha2 as an option
>>> - 3.10.9 alpha as an option
>>>
>>> Is that what you were thinking?
>>
>> I'd prefer to replace 3.5.7 with 3.10.9.
>
> +1
>

-1 (comments below)

>>
>> When 3.10.9 turns GA we may make it default or not. 3.0.35 needs to be
>> kept around due backward support.
>
> Do not forget that 3.10.9-1.0.0 is not only kernel. It's all BSP packages
>
Thanks for pointing this out. I had assumed backward-compatibility with
3.5.7/3.0.35_4.1.0 packages.

Patches haven't yet been submitted for the other bits, have they?

It would be really nice if this update came with a bit more commentary
about ABI and functional compatibility rather than a single patch
submission and a new branch magically appearing on git.freescale.com.

I'd really like to see Dora become a stable platform for those wanting
to test the full functionality of their boards. We never really had
that for kernel versions 3.0.35_4.0.0, and only have that for
3.0.35_4.1.0 on Dora.

If there isn't some form of PREFERRED_VERSION_ support for 3.0.35_4.1.0
that allows a stable, fully-functional build, I think that 3.10.9 should
be pushed into either "master" or a "next" branch.

What's more, I think it's very important for different boards to be
able to specify which kernel version is recommended for each, since
the efforts behind them progress along different time-lines.

If we don't have the structure to support this, each board vendor
will (and should) probably plan on forking meta-freescale for their
own efforts, which would be a shame.

Regards,


Eric