[meta-freescale] i.MX 3.10.31-1.1.0_beta release - community feedback requested
Eric Nelson
eric.nelson at boundarydevices.com
Tue Aug 19 08:55:58 PDT 2014
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