From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 5C284E004FF; Tue, 19 Aug 2014 09:01:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from ptmx.org (ptmx.org [178.63.28.110]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id A0F39E0034C for ; Tue, 19 Aug 2014 09:01:15 -0700 (PDT) Received: from [10.1.14.248] (vpn.streamunlimited.com [91.114.0.140]) by ptmx.org (Postfix) with ESMTPSA id 8F3B222533; Tue, 19 Aug 2014 18:01:12 +0200 (CEST) Message-ID: <53F374C8.6090201@pseudoterminal.org> Date: Tue, 19 Aug 2014 18:01:12 +0200 From: Carlos Rafael Giani User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Nelson , Otavio Salvador , Lauren Post References: <8f1e8166115a4a4381ded78a5536c001@BY2PR03MB379.namprd03.prod.outlook.com> <23db6296a5b24ce3accdde41476d7d6d@DM2PR0301MB0701.namprd03.prod.outlook.com> <53F3738E.4040902@boundarydevices.com> In-Reply-To: <53F3738E.4040902@boundarydevices.com> Cc: "meta-freescale@yoctoproject.org" Subject: Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:01:22 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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