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

[Eric Nelson]

Hi Otavio,

On 04/06/2015 01:38 PM, Otavio Salvador wrote:
> 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.
> 

That's true, but until the 3.14 kernel has some time in the wild,
there is still the possibility of regression.

>>> 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.
> 

How about this as a compromise?
	- Add 3.14 as new components, then
	- remove 3.10.53 in an explicit patch set

This might make it easier for those who want to stick with 3.10.53
for a while.

Otherwise, you are forcing users to pin their down-stream repositories
at versions that precede the introduction of 3.14 or go through a
complete kernel re-test.

Production users should probably not be on the master branch anyway,
but I suspect that some folks are doing that.

Regards,


Eric