Hi Otavio, On 04/06/2015 01:38 PM, Otavio Salvador wrote: > On Mon, Apr 6, 2015 at 5:15 PM, Eric Nelson > <[email protected]> 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 <[email protected]> >>> 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 -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
