[meta-freescale] [meta-fsl-arm][PATCH 01/11] linux-imx: Upgrade to 3.14.28-1.0.0 GA version

[Otavio Salvador]

On Mon, Apr 6, 2015 at 5:15 PM, Eric Nelson
<eric.nelson at boundarydevices.com> wrote:
> Hi Otavio and Lauren,
>
> On 04/06/2015 09:26 AM, Otavio Salvador wrote:
>> On Mon, Apr 6, 2015 at 12:36 PM, Lauren Post <Lauren.Post at freescale.com> wrote:
>>> 3.10.53 only exists in master branch now so to remove it means it will not exist on any branch.
>>
>> It exists in Git so if someone ever wants or need it, can easily
>> revert the patch and use.
>>
>>> In past we only removed kernel versions that exist in other branches.
>>
>> It was just by coincidence because of the release cadence matched the branching.
>>
>>> I believe it is best to leave 3.10.53 and remove in master branch after fido branch is created.
>
> What's the plan for the default FSL kernel in fido?
>
> If it's 3.14, then it seems unlikely that folks will be using 3.10.53.

3.14.

>> I see no reason to keep it around and untested from now on. Community
>> resources for test are restrict so it will end untested plus the more
>> people relying on 3.14 the better as it is closer to mainline.
>>
>
> Can you clarify what you mean by 'it'?

I mean it is easier to make backports of features/drivers when using
3.14-based kernel than 3.10. So new users, when developing on top of
community, should use 3.14 for custom boards. 3rd parties are free to
choose to keep 3.10.53 or 3.14 in meta-fsl-arm-extra as their kernel,
depending on their schedule/convenience, as GPU is compatible.

>> Someone one has any technical reason to keep it around?
>>
>
> If you're referring to 3.10.53 recipe for Freescale kernel, the
> tag/branch in git.freescale.com should be sufficient.

Agreed.

> Looking at Otavio's patch set, it appears that the changes include
> both kernel updates as well as some remaining packages (firmware-imx,
> imx-test, and such) that are named to reflect the kernel version
> numbering.
>
>         https://lists.yoctoproject.org/pipermail/meta-freescale/2015-April/013274.html

Yes. This is mostly due the EULA change as the components changes are
minimal, if any.

> Having those old recipes around is probably more useful than the
> kernel, since I don't think they're all backed by proper git
> repositories.

The recipes are. They are the current master ones so they are
available on Git history if needed.

> How about just tagging/branching meta-fsl-* with a 3.10.53 name to
> make it easy to grab the set from before the switch?

I am not a big fan of this. For tagging we've been following Yocto
Project schedule and we didn't use BSP version on those as we support
all SoCs, not just one. Branching is even worse as it will pass the
feel we are going to maintain it.

FSL for example didn't send the 3.10.53-1.1.1 updates as 3.14.28-1.0.0
is the current GA so if someone wants to use 3.10.53 I think FSL
layers is the best choice.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750