Hello everyone, (Included all people who replied in Cc)
On Mon, Aug 18, 2014 at 12:32 PM, Lauren Post <[email protected]> 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. 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. 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. 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? 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. 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. Best Regards, -- 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 -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
