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

[zhenhua.luo at freescale.com]

Hi Bob, 

The QorIQ SDK always bases on the stable Yocto release, e.g. SDK 1.6 uses Yocto 1.6(daisy), besides upstream all SDK recipes in master to ensure those content is included in the upcoming Yocto release(Yocto 1.7),  the SDK 1.6 release bits should also be upstreamed to Yocto 1.6(daisy), so the fixes for SDK 1.6 can be submitted against daisy branch, does this sound good for you? 

With regard to the bugs of QorIQ SDK, you can submit in Yocto Bugzilla until the FSL public bug report system is ready. 


Best Regards,

Zhenhua

> -----Original Message-----
> From: Bob Cochran [mailto:yocto at mindchasers.com]
> Sent: Thursday, September 11, 2014 11:46 PM
> To: Luo Zhenhua-B19537
> Cc: meta-freescale at yoctoproject.org
> Subject: Re: [meta-freescale] 9/8 community meeting, was [RFC] The proposal
> of FSL QorIQ SDK upstream
> 
> 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