[meta-freescale] 9/8 community meeting, was [RFC] The proposal of FSL QorIQ SDK upstream

[Bob Cochran]

On 09/09/2014 09:28 AM, zhenhua.luo at freescale.com wrote:
> Bob,
>
> Please see my inline comments.
>
>> -----Original Message-----
>> From: meta-freescale-bounces at yoctoproject.org [mailto:meta-freescale-
>> bounces at yoctoproject.org] On Behalf Of Bob Cochran
>> Sent: Monday, September 08, 2014 9:05 AM
>>
>> On 07/16/2014 02:00 AM, zhenhua.luo at 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 at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale