[meta-freescale] i.MX 3.10.31-1.1.0_beta release - community feedback requested
Carlos Rafael Giani
dv at pseudoterminal.org
Tue Aug 19 09:01:12 PDT 2014
Well, of course Freescale is interested in option 2, since it helps with
their kernel development :)
But think about it this way:
you are a customer, and are using the beta kernel, because that's what
is in Yocto Project 1.7. Something goes wrong. You contact your
Freescale FAE. Response: "we can't help you, because you are using an
unsupported kernel". This is the main problem. Not necessarily the
stability of the beta kernel, but the lack of Freescale support.
On 2014-08-19 17:55, Eric Nelson wrote:
> Thanks Otavio,
>
> On 08/19/2014 06:59 AM, Otavio Salvador wrote:
>> Hello everyone,
>>
>> (Included all people who replied in Cc)
>>
>> On Mon, Aug 18, 2014 at 12:32 PM, Lauren Post <Lauren.Post at freescale.com> wrote:
>>> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week. My team will be up-streaming this release next week into master-next branch.
>> ...
>>> We have a question to community. Our 3.10.31-1.1.0 GA release is not public/released until January. We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
>>>
>>> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>>> o This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>>> o Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>>> o 3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
>>> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>>> o This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>>> o Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>>> o Beta is not supported (by freescale/for production/by SR). However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
>>>
>>> Please provide your feedback. Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
>> I gave some thought about community feedback regarding these two options.
>>
>> First I'd like to analyse the facts about the two options:
>>
>> - Option 1 - Conservative option
>> - 3.10.31-beta is merged ASAP in master-next
>> - Yocto Project 1.7 is released with 3.10.17-ga
>> - in October, when we branch 1.7, 3.10.31-beta is merged in master
>>
>> Consequences:
>> - Yocto Project 1.7 has 3.10.17 with GA quality for i.MX6 (with
>> all patch released included - 1.0.1, …)
>> - Yocto Project 1.7 has support for the BSP for i.MX6, by FSL
>> - Yocto Project 1.7 is a stable branch with a stable BSP (GA
>> quality) for i.MX6
>> - Freescale allow customers to use Yocto Project 1.7 for production
>> - Pre-test of 3.10.31-beta is done in master-next focusing Yocto
>> Project 1.8 development cycle
>> - Test of 3.10.310-beta is done in master as soon as Yocto Project
>> 1.7 is branched
>>
>> - Option 2 - Aggressive option
>> - 3.10.31-beta is merged ASAP in master
>> - Yocto Project 1.7 is released with 3.10.31-bea with Beta quality
>> - Yocto Project 1.7 has 3.10.31 with GA quality merged (expected) in January
>>
>> Consequences:
>> - Yocto Project 1.7 has 3.10.31 with Beta quality for i.MX6
>> - Yocto Project 1.7 DOES NOT has support for the BSP for i.MX6, by FSL
>> - Yocto Project 1.7 is a stable branch with a Beta BSP for i.MX6
>> - Freescale advise customers to use Daisy (Yocto Project 1.6 with
>> 3.10.17-ga) for production until 3.10.31-ga is released and merged
>> into Yocto Project 1.7 (expected in January)
>> - Pre-test of 3.10.31-beta is done in master until end-September
>> as we need to branch for Yocto Project 1.7 release
>> - Test of 3.10.31-beta is done in Yocto Project 1.7 STABLE release
>>
>> - Option 3 - Maintain both BSPs around
>> - I deny this as the amount of effort to support and test all this
>> would increase my maintainer work and I see no real benefit on this.
>> So this is a unfeasible.
>>
> This is an interesting personality test.
>
> So far, it sounds as if Otavio and Carlos are the conservative
> ones, and Alfonso, Sébastien and I are "aggressive".
>
>> So before I do a clear statement about my preferred option I would
>> like to extern some thoughts about what I think it is important to
>> ponder when choosing either option.
>>
>> Since the creation of FSL Community BSP we (here I include the most
>> active contributors in the community) been working in to make the user
>> experience as good as possible: code quality, stability and
>> flexibility has always been our goals.
>>
> Many thanks for this!
>
>> I think we are doing a great job here. I am aware of several examples
>> where Freescale release fails badly and FSL Community BSP works fine,
>> this can be seen in several examples as:
>>
>> - use of 3rd-party boards
>> - kernel customizability
>>
>> The Freescale release is tested only for the boards they enumerate in
>> the Release Notes which comes with the release.
>>
> Please note that Freescale's Beta testing has been done against
> components of Yocto 1.7 if I'm not mistaken, and only against
> their kernel sources.
>
>> Currently we have 3 vendors which still use 3.0.35 (2 of those -
>> Congatec and SolidRun - does not have 3.10.17 kernels integrated yet)
>> and moving to a newer BSP means breaking all previous kernels as the
>> newer GPU imposes a kernel update. Is it realistic to expect those all
>> vendors to move to 3.10.31-beta in less than 2 months?
>>
> The situation is a it messier than that. We also "still use" 3.0.35
> kernels for some of our customers, and that's a situation likely to
> persist for a long while. I suspect that the same is true for any
> vendor doing custom designs or offering SOMs.
>
> The transition to device tree will be a long one.
>
>> Trustability is something quite difficult to build, but dead easy to
>> lost. If we release Yocto Project 1.7 with the 3.10.31-beta BSP and it
>> has a severe issue, we will have a broken release until February - at
>> best. The community cannot be expected to provide an extended test of
>> the FSL Community BSP, especially because of the short time before we
>> need to branch for 1.7 release.
>>
> I think this is the crux of the question: how much weight do you
> give to the "-beta" and "-GA" tags?
>
> In my experience, Freescale does a pretty good job of testing
> even prior to "-alpha" and "-beta" releases. Without going through
> the entire patch sets, my suspicion is that there are more bug
> fixes in the 3.10.31 kernel than newly-introduced bugs.
>
> e.g., this PCIe bug fix is present in 3.10.31, but doesn't appear
> to be present in 3.10.17_1.0.1:
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.31_1.1.0_beta&id=c8a6b97
>
> At this stage, I've not spent much time with 3.10.31, and I've
> only used it on Freescale hardware (SABRE SD), and I suspect
> that the same is true for others on the list.
>
>> All that said, I vote for Option 1 - conservative.
>>
>> The possible feedback we, as community, can provide to Freescale I
>> think won't be decisive for the quality of 3.10.31 release. As you all
>> can see our bugzilla[1] has feedback entries which are more than one
>> year[2][3] old and there is no one at Freescale responsible to /fix/
>> these or comment officially on those.
>>
>> 1. https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=meta-fsl-arm
>> 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=5098 (opened in
>> September of 2013)
>> 3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=4510 (opened in
>> May of 2013)
>>
>> I hope this makes clear my position. If most of the community prefer
>> the Option 2 I will accept it, but I think it is not the best choice.
>>
> I'll re-iterate my preference for Option 2, and I think a key piece of
> the equation is Lauren's statement that Freescale's preference is
> Option 2.
>
> As always, the key bits are those which we don't control (closed
> source binaries), and I suspect that the kernel support for those
> is fairly easy to backport to a 3.10.17 kernel if a vendor wants
> to stay there.
>
> Back-ports to 3.0.35 will naturally be harder, but we don't solve
> this with Option 1 either.
>
> Regards,
>
>
> Eric
More information about the meta-freescale
mailing list