From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 4C4E1E004FF; Tue, 19 Aug 2014 08:56:15 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.192.170 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id A0346E0034C for ; Tue, 19 Aug 2014 08:56:06 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id g10so10071531pdj.1 for ; Tue, 19 Aug 2014 08:56:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2gtDllhT5AiuayngeJqwk4qiiYV3wtqEdgpX8VHf9tY=; b=kqcbHvTa2vnaaTEIB4VobjXl3PPC026f3dSiZslPK52yyoJwcOLlgFa/atw7pJZFzW XKAjXn2qvtKmb9aDM6m2DikebEzU+sUbfYYptfPSMkboOikhc05syAsONCJmCsup25Rk bAyFFnVgf/P1QdWuRPEs4/932fkQ/y5VGnRyWuFM+Vat/2sLXYnNdPMSArmfIcZ3D32x tEnPehABt2jQIxDMXfqCWhlGoJBpDqBgUjCoN/9aQRPt8dE6z+ap6i4wI5MN9baXEAMd 2GyqErOQgNCESMIenIQwhCavkqCE0i6vQrMjyXVzGAi0RR+1XYyVqKot/EINuq2mr5y/ Ss9w== X-Gm-Message-State: ALoCoQkGlJ9x7SejrziCuCZ6cSxRctjqJDrfYat3/ptZvOS1XQo87yYXrGs+FC+1fuUFgl/RYNfc X-Received: by 10.68.129.99 with SMTP id nv3mr44245051pbb.128.1408463764699; Tue, 19 Aug 2014 08:56:04 -0700 (PDT) Received: from [192.168.1.11] ([63.226.49.26]) by mx.google.com with ESMTPSA id oo3sm15361023pdb.64.2014.08.19.08.56.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Aug 2014 08:56:03 -0700 (PDT) Message-ID: <53F3738E.4040902@boundarydevices.com> Date: Tue, 19 Aug 2014 08:55:58 -0700 From: Eric Nelson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Otavio Salvador , Lauren Post References: <8f1e8166115a4a4381ded78a5536c001@BY2PR03MB379.namprd03.prod.outlook.com> <23db6296a5b24ce3accdde41476d7d6d@DM2PR0301MB0701.namprd03.prod.outlook.com> In-Reply-To: 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 15:56:15 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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