From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id AC40EE006EF; Thu, 11 Sep 2014 08:45:36 -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 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 5E690E006C5 for ; Thu, 11 Sep 2014 08:45:33 -0700 (PDT) Received: from [192.168.1.10] (c-68-38-40-177.hsd1.nj.comcast.net [68.38.40.177]) by smtp.webfaction.com (Postfix) with ESMTP id 1B6F222905DB; Thu, 11 Sep 2014 15:45:32 +0000 (UTC) Message-ID: <5411C39A.7050006@mindchasers.com> Date: Thu, 11 Sep 2014 11:45:30 -0400 From: Bob Cochran User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "zhenhua.luo@freescale.com" References: <540D00B7.5060604@mindchasers.com> <88f8ceeb9b3b442b8797d900cbc26cfe@CY1PR0301MB0715.namprd03.prod.outlook.com> In-Reply-To: <88f8ceeb9b3b442b8797d900cbc26cfe@CY1PR0301MB0715.namprd03.prod.outlook.com> Cc: "meta-freescale@yoctoproject.org" Subject: Re: 9/8 community meeting, was [RFC] The proposal of FSL QorIQ SDK upstream 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: Thu, 11 Sep 2014 15:45:36 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 09/09/2014 09:28 AM, zhenhua.luo@freescale.com wrote: > Bob, > > Please see my inline comments. > >> -----Original Message----- >> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale- >> bounces@yoctoproject.org] On Behalf Of Bob Cochran >> Sent: Monday, September 08, 2014 9:05 AM >> >> On 07/16/2014 02:00 AM, zhenhua.luo@freescale.com wrote: >>> >>> More to do >>> • Setup public bug management system for FSL SDKs. >>> • Push all modules to public git repository to ensure FSL community BSP >> sync with FSL released SDK. >>> • Setup an external mailing list for external git repository for FSL >> SDK discussion, patch submission, patch review. >>> • Setup an patch management tool(patchwork or gerrit) to manage patches >> from community. >>> • Enhance the commit message in patch to facilitate the patch search >> for specific issue. >> >> Can we get an update on the items listed above during tomorrow's >> community meeting (or soon afterwards)? > [Luo Zhenhua-B19537] Those items are being worked on, I will send an separated email when the infrastructure is available. > >> Also, I had previously asked about creating a branch on meta-fsl-ppc that >> could be used to track patches / improvements for SDK1.6 in addition to >> master, which I think is basically being used to set up 1.7. > [Luo Zhenhua-B19537] Why can't those fixes be submitted to master directly? Hi Zhenhua, Thank you for the reply. A master branch and some documentation is great for getting a board up & running, but I don't think it is sufficient for putting together a stable code base (snap shot) and then working out the defects. I have been assuming that each FSL SDK release is a starting point for a product code base, and I am hoping that the FSL Community becomes the venue where each SDK (perhaps mirrored as a particular meta-fsl-ppc branch) can be tested and improved to the point that it is stable & product worthy for various customer targets. If all patches, upgrades, and new code goes to the same (meta-fsl-ppc) master branch, then the line is blurred between improving the last SDK and setting up the next, which isn't necessarily more stable than the previous one. Along the same line, I ask that the community works together to develop a statement on a process for using the code available in the community repos to develop, test, and release a product. I hope you and others believe this is an attainable and worthy goal. I would hope that a single process could eventually apply to both QorIQ and i.MX. > >> I need to start getting after some bugs on SDK1.6 related to various >> kernel oops that pop up inconsistently. I would love to see an >> infrastructure in place to help with this. > [Luo Zhenhua-B19537] Can you please summarize the defects of SDK 1.6 and post by email before infrastructure readiness? Regarding a defect list, I'm going to start investigating a couple of them tomorrow. As typical, the problems I see are inconsistent. The two I'm going to try to recreate and document are i) kernel oops during user space init during; ii) kernel oops during nfs nework copy (of rootfs onto an SSD). I hope to have some useful defect facts by next week. During the 9/8 community call, I was asked to enter a bug report in yocto bugzilla as a test case. Are you OK with me entering a new bugzilla item? Thanks, Bob > > > Best Regards, > > Zhenhua > >> Thanks, >> >> Bob >> >> >> >> >> >> >>> >>> >>> Best Regards, >>> >>> Zhenhua >>> >> >> -- >> _______________________________________________ >> meta-freescale mailing list >> meta-freescale@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/meta-freescale