Yocto branches policy for concurrent SDK releases

Yocto branches policy for concurrent SDK releases

[Zhenhua Luo]

Hi all,

Currently concurrent SDKs are on-going(e.g. SDK 1.5, T1040/T2080, LS1, etc), the same Yocto branch is used for multiple releases, there is conflict of Yocto recipes for different SDKs.

To resolve above issue, following branch mechanism will be used:

1. For those layers without conflict(poky, meta-oe, meta-virtualization and layers reused from community), same branch will be used and no extra branches need to be created, change for those layer should be upstreamed synchronously. 

2. For those layers with conflict, the branch specific to SDK are created, currently meta-fsl-ppc and meta-fsl-networking have conflict for different SDKs. Following branches will co-exist for such layers. 
   a. Yocto release branch: dylan, dora. the common changes for all SDKs should be submitted against this branch and cherry-picked to SDK specific branches. The changes should be upstreamed synchronously. 
   b. SDK specific branch: dylan-sdk1.5, dylan-t1_t2, etc. The SDK specific change should be submitted against SDK branch, when SDK is formally released, the changes will be upstreamed.  

Please let me know if any comment.  


Best Regards,

Zhenhua

Re: Yocto branches policy for concurrent SDK releases

[Bob Cochran]

On 11/22/2013 05:43 AM, Zhenhua Luo wrote:
> Hi all,
>
> Currently concurrent SDKs are on-going(e.g. SDK 1.5, T1040/T2080, LS1, etc), the same Yocto branch is used for multiple releases, there is conflict of Yocto recipes for different SDKs.
>
> To resolve above issue, following branch mechanism will be used:
>
> 1. For those layers without conflict(poky, meta-oe, meta-virtualization and layers reused from community), same branch will be used and no extra branches need to be created, change for those layer should be upstreamed synchronously.
>
> 2. For those layers with conflict, the branch specific to SDK are created, currently meta-fsl-ppc and meta-fsl-networking have conflict for different SDKs. Following branches will co-exist for such layers.
>     a. Yocto release branch: dylan, dora. the common changes for all SDKs should be submitted against this branch and cherry-picked to SDK specific branches. The changes should be upstreamed synchronously.
>     b. SDK specific branch: dylan-sdk1.5, dylan-t1_t2, etc. The SDK specific change should be submitted against SDK branch, when SDK is formally released, the changes will be upstreamed.


Hi Zhenhua,

Any plans to create a repo for meta-fsl-networking on git.yoctoproject 
for Power / QorIQ developers?

It would be good for yocto users, such as myself, to be able to build 
something incremental between the SDK releases using updated / patched 
recipes pulled from the yocto repos, which should include 
meta-fsl-networking.

Say I wanted to propose a patch to a recipe like fsl-image-full, which 
is in meta-fsl-networking, how would I go about it?

Last February (2013), you proposed an FSL Yocto layers reorg that merged 
layerscape/ARM with Power for QorIQ.  I imagine you're getting close to 
having something internally.  Can you please share the vision with us 
along with whether it will be public on the yocto project (as opposed to 
kept under wraps with incremental SDK releases)?

Thank you,

Bob






>
> Please let me know if any comment.
>
>
> Best Regards,
>
> Zhenhua
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: [mcswdev] Yocto branches policy for concurrent SDK releases

[zhenhua.luo]

Hi Bob, 

Sorry for the late response. 

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Friday, January 10, 2014 4:25 AM
> 
> Any plans to create a repo for meta-fsl-networking on git.yoctoproject
> for Power / QorIQ developers?
[Luo Zhenhua-B19537] meta-fsl-networking layer manages the packages maintained internally, so the layer can't be upstreamed. 

> It would be good for yocto users, such as myself, to be able to build
> something incremental between the SDK releases using updated / patched
> recipes pulled from the yocto repos, which should include meta-fsl-
> networking.
> 
> Say I wanted to propose a patch to a recipe like fsl-image-full, which is
> in meta-fsl-networking, how would I go about it?
[Luo Zhenhua-B19537] For such case, we will consider to move the demo image recipes into meta-fsl-ppc layer. 

> Last February (2013), you proposed an FSL Yocto layers reorg that merged
> layerscape/ARM with Power for QorIQ.  I imagine you're getting close to
> having something internally.  Can you please share the vision with us
> along with whether it will be public on the yocto project (as opposed to
> kept under wraps with incremental SDK releases)?
[Luo Zhenhua-B19537] Currently we are working on it, and will publish the staffs publicly when it is ready. 


Best Regards,

Zhenhua

Re: Yocto branches policy for concurrent SDK releases

[Zhenhua Luo]

Please ignore, sorry for the noise. 


Best Regards,

Zhenhua

> -----Original Message-----
> From: Luo Zhenhua-B19537
> Sent: Friday, November 22, 2013 6:44 PM
> To: Software Development Power Arch Multicore
> Cc: yocto@yoctoproject.org
> Subject: [mcswdev] Yocto branches policy for concurrent SDK releases
> Importance: High
> 
> Hi all,
> 
> Currently concurrent SDKs are on-going(e.g. SDK 1.5, T1040/T2080, LS1,
> etc), the same Yocto branch is used for multiple releases, there is
> conflict of Yocto recipes for different SDKs.
> 
> To resolve above issue, following branch mechanism will be used:
> 
> 1. For those layers without conflict(poky, meta-oe, meta-virtualization
> and layers reused from community), same branch will be used and no extra
> branches need to be created, change for those layer should be upstreamed
> synchronously.
> 
> 2. For those layers with conflict, the branch specific to SDK are created,
> currently meta-fsl-ppc and meta-fsl-networking have conflict for
> different SDKs. Following branches will co-exist for such layers.
>    a. Yocto release branch: dylan, dora. the common changes for all SDKs
> should be submitted against this branch and cherry-picked to SDK specific
> branches. The changes should be upstreamed synchronously.
>    b. SDK specific branch: dylan-sdk1.5, dylan-t1_t2, etc. The SDK
> specific change should be submitted against SDK branch, when SDK is
> formally released, the changes will be upstreamed.
> 
> Please let me know if any comment.
> 
> 
> Best Regards,
> 
> Zhenhua