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