i.MX 3.10.31-1.1.0_beta release - community feedback requested

i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Lauren Post]

Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.

This release has the following new features
	-  Kernel upgrade to 3.10.31
	-  Supports new i.MX6 SoloX SabreSD machine
	-  U-Boot-imx upgrade to 2014.04 version
	-  New GPU Vivante version v5
		o   Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs.
		o   DirectFB 1.7.1
		o   Wayland 1.5
		o   Xorg 1.15
		o   Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU.
		o   i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends.
		o   fsl-gpu-sdk version 1.2 supporting all backends.
	-   Multimedia Features
		o   Freescale Gstreamer 1.0 support
		o   Gstreamer 0.1 Fixes
		o   Upgraded VPU firmware and wrapper software
		o   G2D integration 

We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.

- Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
	o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
	o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
	o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
- Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
	o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
	o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
	o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.

Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.

Thanks,
Lauren Post
Yocto Project i.MX Team Lead

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Alfonso Tamés]

Option 2! 3.10.17 seems to have the EGL backend broken so let's embrace the future in master branch.

Thanks,

Alfonso

> On 18/08/2014, at 10:32, Lauren Post <Lauren.Post@freescale.com> wrote:
> 
> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
> 
> This release has the following new features
>    -  Kernel upgrade to 3.10.31
>    -  Supports new i.MX6 SoloX SabreSD machine
>    -  U-Boot-imx upgrade to 2014.04 version
>    -  New GPU Vivante version v5
>        o   Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs.
>        o   DirectFB 1.7.1
>        o   Wayland 1.5
>        o   Xorg 1.15
>        o   Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU.
>        o   i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends.
>        o   fsl-gpu-sdk version 1.2 supporting all backends.
>    -   Multimedia Features
>        o   Freescale Gstreamer 1.0 support
>        o   Gstreamer 0.1 Fixes
>        o   Upgraded VPU firmware and wrapper software
>        o   G2D integration 
> 
> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
> 
> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>    o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>    o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>    o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>    o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>    o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>    o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
> 
> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
> 
> Thanks,
> Lauren Post
> Yocto Project i.MX Team Lead
> 
> -- 
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Eric Nelson]

On 08/18/2014 08:54 AM, Alfonso Tamés wrote:
> Option 2! 3.10.17 seems to have the EGL backend broken so let's embrace the future in master branch.
> 

+1

> Thanks,
> 
> Alfonso
> 
>> On 18/08/2014, at 10:32, Lauren Post <Lauren.Post@freescale.com> wrote:
>>
>> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
>>
>> This release has the following new features
>>    -  Kernel upgrade to 3.10.31
>>    -  Supports new i.MX6 SoloX SabreSD machine
>>    -  U-Boot-imx upgrade to 2014.04 version
>>    -  New GPU Vivante version v5
>>        o   Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs.
>>        o   DirectFB 1.7.1
>>        o   Wayland 1.5
>>        o   Xorg 1.15
>>        o   Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU.
>>        o   i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends.
>>        o   fsl-gpu-sdk version 1.2 supporting all backends.
>>    -   Multimedia Features
>>        o   Freescale Gstreamer 1.0 support
>>        o   Gstreamer 0.1 Fixes
>>        o   Upgraded VPU firmware and wrapper software
>>        o   G2D integration 
>>
>> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
>>
>> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>>    o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>>    o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>>    o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
>> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>>    o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>>    o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>>    o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
>>
>> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
>>

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Carlos Rafael Giani]

The EGL backend is broken? I didn't notice. I ran chromium with EGL and 
GLESv2 based rendering successfully with it.

I vote for option 1. Option 2 means there wouldn't be an FSL supported 
kernel in master until January, which is a rather strange situation. I 
understand FSL wants to maximize the feedback they get, but isn't it 
important to have a FSL supported kernel available? Yes, it is there in 
daisy, but master is a reviewed branch, so customers can actually use 
it. Instead, I'd keep 3.10.17 , but encourage customers and hobbyists to 
try out the beta, since they would benefit from this as well.

On 08/18/2014 05:54 PM, Alfonso Tamés wrote:
> Option 2! 3.10.17 seems to have the EGL backend broken so let's embrace the future in master branch.
>
> Thanks,
>
> Alfonso
>
>> On 18/08/2014, at 10:32, Lauren Post <Lauren.Post@freescale.com> wrote:
>>
>> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
>>
>> This release has the following new features
>>     -  Kernel upgrade to 3.10.31
>>     -  Supports new i.MX6 SoloX SabreSD machine
>>     -  U-Boot-imx upgrade to 2014.04 version
>>     -  New GPU Vivante version v5
>>         o   Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs.
>>         o   DirectFB 1.7.1
>>         o   Wayland 1.5
>>         o   Xorg 1.15
>>         o   Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU.
>>         o   i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends.
>>         o   fsl-gpu-sdk version 1.2 supporting all backends.
>>     -   Multimedia Features
>>         o   Freescale Gstreamer 1.0 support
>>         o   Gstreamer 0.1 Fixes
>>         o   Upgraded VPU firmware and wrapper software
>>         o   G2D integration
>>
>> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
>>
>> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>>     o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>>     o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>>     o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
>> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>>     o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>>     o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>>     o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
>>
>> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
>>
>> Thanks,
>> Lauren Post
>> Yocto Project i.MX Team Lead
>>
>> -- 
>> _______________________________________________
>> meta-freescale mailing list
>> meta-freescale@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[John Weber]

[-- Attachment #1: Type: text/plain, Size: 4370 bytes --]

The beta will be around for 3+ months after the release of 1.7, I don't
think we have an option but to keep 3.10.17 the preferred version.   Unless
it was really good.  And even it it was great, I wouldn't want to remove
3.10.17 recipes as that could be a fallback for users.

On Mon, Aug 18, 2014 at 2:35 PM, Carlos Rafael Giani <dv@pseudoterminal.org>
wrote:

> The EGL backend is broken? I didn't notice. I ran chromium with EGL and
> GLESv2 based rendering successfully with it.
>
> I vote for option 1. Option 2 means there wouldn't be an FSL supported
> kernel in master until January, which is a rather strange situation. I
> understand FSL wants to maximize the feedback they get, but isn't it
> important to have a FSL supported kernel available? Yes, it is there in
> daisy, but master is a reviewed branch, so customers can actually use it.
> Instead, I'd keep 3.10.17 , but encourage customers and hobbyists to try
> out the beta, since they would benefit from this as well.
>
>
> On 08/18/2014 05:54 PM, Alfonso Tamés wrote:
>
>> Option 2! 3.10.17 seems to have the EGL backend broken so let's embrace
>> the future in master branch.
>>
>> Thanks,
>>
>> Alfonso
>>
>>  On 18/08/2014, at 10:32, Lauren Post <Lauren.Post@freescale.com> wrote:
>>>
>>> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by
>>> next week.  My team will be up-streaming this release next week into
>>> master-next branch.
>>>
>>> This release has the following new features
>>>     -  Kernel upgrade to 3.10.31
>>>     -  Supports new i.MX6 SoloX SabreSD machine
>>>     -  U-Boot-imx upgrade to 2014.04 version
>>>     -  New GPU Vivante version v5
>>>         o   Supports OpenGLES 3.0 APIs with backward compatibility with
>>> earlier version APIs.
>>>         o   DirectFB 1.7.1
>>>         o   Wayland 1.5
>>>         o   Xorg 1.15
>>>         o   Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX
>>> parts containing 3D GPU.
>>>         o   i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer
>>> backends.
>>>         o   fsl-gpu-sdk version 1.2 supporting all backends.
>>>     -   Multimedia Features
>>>         o   Freescale Gstreamer 1.0 support
>>>         o   Gstreamer 0.1 Fixes
>>>         o   Upgraded VPU firmware and wrapper software
>>>         o   G2D integration
>>>
>>> We have a question to community.  Our 3.10.31-1.1.0 GA release is not
>>> public/released until January.   We have two options for upstream of
>>> 3.10.31 into meta-fsl-arm and would like feedback from community.
>>>
>>> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch
>>> master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept
>>> or early October
>>>     o   This means that 3.10.31-1.1.0_beta will be in master-next branch
>>> during September.
>>>     o   Also means Freescale will get less feedback from community to
>>> fix for our 3.10.31-1.1.0 GA release.
>>>     o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only
>>> in April 2015.
>>> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove
>>> 3.10.17 from master branch.
>>>     o   This means Yocto Project 1.7 release will not be production code
>>> for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>>>     o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX
>>> and Graphics as part of Yocto Project 1.7 in January.
>>>     o   Beta is not supported (by freescale/for production/by SR).
>>> However bugs can be sent to imx-community and if time before GA code freeze
>>> Freescale can try to fix in our GA release.
>>>
>>> Please provide your feedback.  Freescale prefers Option 2 because we can
>>> get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we
>>> will abide by community wishes if they prefer Option 1.
>>>
>>> Thanks,
>>> Lauren Post
>>> Yocto Project i.MX Team Lead
>>>
>>> --
>>> _______________________________________________
>>> meta-freescale mailing list
>>> meta-freescale@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-freescale
>>>
>>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>

[-- Attachment #2: Type: text/html, Size: 5477 bytes --]

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Alfonso Tamés]

Qt5 and the Vivante demos fail in EGL: https://community.freescale.com/thread/326402

On Aug 18, 2014, at 2:35 PM, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:

> The EGL backend is broken? I didn't notice. I ran chromium with EGL and GLESv2 based rendering successfully with it.
> 
> I vote for option 1. Option 2 means there wouldn't be an FSL supported kernel in master until January, which is a rather strange situation. I understand FSL wants to maximize the feedback they get, but isn't it important to have a FSL supported kernel available? Yes, it is there in daisy, but master is a reviewed branch, so customers can actually use it. Instead, I'd keep 3.10.17 , but encourage customers and hobbyists to try out the beta, since they would benefit from this as well.
> 
> On 08/18/2014 05:54 PM, Alfonso Tamés wrote:
>> Option 2! 3.10.17 seems to have the EGL backend broken so let's embrace the future in master branch.
>> 
>> Thanks,
>> 
>> Alfonso
>> 
>>> On 18/08/2014, at 10:32, Lauren Post <Lauren.Post@freescale.com> wrote:
>>> 
>>> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
>>> 
>>> This release has the following new features
>>>    -  Kernel upgrade to 3.10.31
>>>    -  Supports new i.MX6 SoloX SabreSD machine
>>>    -  U-Boot-imx upgrade to 2014.04 version
>>>    -  New GPU Vivante version v5
>>>        o   Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs.
>>>        o   DirectFB 1.7.1
>>>        o   Wayland 1.5
>>>        o   Xorg 1.15
>>>        o   Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU.
>>>        o   i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends.
>>>        o   fsl-gpu-sdk version 1.2 supporting all backends.
>>>    -   Multimedia Features
>>>        o   Freescale Gstreamer 1.0 support
>>>        o   Gstreamer 0.1 Fixes
>>>        o   Upgraded VPU firmware and wrapper software
>>>        o   G2D integration
>>> 
>>> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
>>> 
>>> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>>>    o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>>>    o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>>>    o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
>>> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>>>    o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>>>    o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>>>    o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
>>> 
>>> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
>>> 
>>> Thanks,
>>> Lauren Post
>>> Yocto Project i.MX Team Lead
>>> 
>>> -- 
>>> _______________________________________________
>>> meta-freescale mailing list
>>> meta-freescale@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-freescale
> 
> -- 
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Sébastien Taylor]

Option 2.  Though I fail to see why 3.10.17 would need to be removed Yocto has no issues supporting multiple versions of packages.  Seems to me supporting both options is win/win for everyone.

On Aug 18, 2014, at 9:32 AM, Lauren Post <lauren.post@freescale.com> wrote:

> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
> 
> This release has the following new features
> 	-  Kernel upgrade to 3.10.31
> 	-  Supports new i.MX6 SoloX SabreSD machine
> 	-  U-Boot-imx upgrade to 2014.04 version
> 	-  New GPU Vivante version v5
> 		o   Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs.
> 		o   DirectFB 1.7.1
> 		o   Wayland 1.5
> 		o   Xorg 1.15
> 		o   Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU.
> 		o   i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends.
> 		o   fsl-gpu-sdk version 1.2 supporting all backends.
> 	-   Multimedia Features
> 		o   Freescale Gstreamer 1.0 support
> 		o   Gstreamer 0.1 Fixes
> 		o   Upgraded VPU firmware and wrapper software
> 		o   G2D integration 
> 
> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
> 
> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
> 	o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
> 	o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
> 	o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
> 	o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
> 	o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
> 	o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
> 
> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
> 
> Thanks,
> Lauren Post
> Yocto Project i.MX Team Lead
> 
> -- 
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Carlos Rafael Giani]

 From my understanding, several parts would be upgraded to 3.10.31-1-1.0 
, not just the kernel. I suppose other drivers would be as well. You'd 
have to keep all of them around. Which is OK for me, but probably not OK 
for the layer maintainers. Comments?

On 08/19/2014 04:32 AM, Sébastien Taylor wrote:
> Option 2.  Though I fail to see why 3.10.17 would need to be removed Yocto has no issues supporting multiple versions of packages.  Seems to me supporting both options is win/win for everyone.
>
> On Aug 18, 2014, at 9:32 AM, Lauren Post <lauren.post@freescale.com> wrote:
>
>> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
>>
>> This release has the following new features
>> 	-  Kernel upgrade to 3.10.31
>> 	-  Supports new i.MX6 SoloX SabreSD machine
>> 	-  U-Boot-imx upgrade to 2014.04 version
>> 	-  New GPU Vivante version v5
>> 		o   Supports OpenGLES 3.0 APIs with backward compatibility with earlier version APIs.
>> 		o   DirectFB 1.7.1
>> 		o   Wayland 1.5
>> 		o   Xorg 1.15
>> 		o   Qt5 fixes for X11, Wayland and Framebuffer backends on i.MX parts containing 3D GPU.
>> 		o   i.MX 6 SoloLite fixes for DirectFB, Wayland and frame buffer backends.
>> 		o   fsl-gpu-sdk version 1.2 supporting all backends.
>> 	-   Multimedia Features
>> 		o   Freescale Gstreamer 1.0 support
>> 		o   Gstreamer 0.1 Fixes
>> 		o   Upgraded VPU firmware and wrapper software
>> 		o   G2D integration
>>
>> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
>>
>> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>> 	o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>> 	o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>> 	o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
>> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>> 	o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>> 	o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>> 	o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
>>
>> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
>>
>> Thanks,
>> Lauren Post
>> Yocto Project i.MX Team Lead
>>
>> -- 
>> _______________________________________________
>> meta-freescale mailing list
>> meta-freescale@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Otavio Salvador]

Hello everyone,

(Included all people who replied in Cc)

On Mon, Aug 18, 2014 at 12:32 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
...
> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
>
> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>         o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>         o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>         o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>         o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>         o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>         o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
>
> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.

I gave some thought about community feedback regarding these two options.

First I'd like to analyse the facts about the two options:

- Option 1 - Conservative option
   - 3.10.31-beta is merged ASAP in master-next
   - Yocto Project 1.7 is released with 3.10.17-ga
   - in October, when we branch 1.7, 3.10.31-beta is merged in master

   Consequences:
    - Yocto Project 1.7 has 3.10.17 with GA quality for i.MX6 (with
all patch released included - 1.0.1, …)
    - Yocto Project 1.7 has support for the BSP for i.MX6, by FSL
    - Yocto Project 1.7 is a stable branch with a stable BSP (GA
quality) for i.MX6
    - Freescale allow customers to use Yocto Project 1.7 for production
    - Pre-test of 3.10.31-beta is done in master-next focusing Yocto
Project 1.8 development cycle
    - Test of 3.10.310-beta is done in master as soon as Yocto Project
1.7 is branched


- Option 2 - Aggressive option
   - 3.10.31-beta is merged ASAP in master
   - Yocto Project 1.7 is released with 3.10.31-bea with Beta quality
   - Yocto Project 1.7 has 3.10.31 with GA quality merged (expected) in January

   Consequences:
    - Yocto Project 1.7 has 3.10.31 with Beta quality for i.MX6
    - Yocto Project 1.7 DOES NOT has support for the BSP for i.MX6, by FSL
    - Yocto Project 1.7 is a stable branch with a Beta BSP for i.MX6
    - Freescale advise customers to use Daisy (Yocto Project 1.6 with
3.10.17-ga) for production until 3.10.31-ga is released and merged
into Yocto Project 1.7 (expected in January)
    - Pre-test of 3.10.31-beta is done in master until end-September
as we need to branch for Yocto Project 1.7 release
    - Test of 3.10.31-beta is done in Yocto Project 1.7 STABLE release

- Option 3 - Maintain both BSPs around
   - I deny this as the amount of effort to support and test all this
would increase my maintainer work and I see no real benefit on this.
So this is a unfeasible.


So before I do a clear statement about my preferred option I would
like to extern some thoughts about what I think it is important to
ponder when choosing either option.

Since the creation of FSL Community BSP we (here I include the most
active contributors in the community) been working in to make the user
experience as good as possible: code quality, stability and
flexibility has always been our goals.

I think we are doing a great job here. I am aware of several examples
where Freescale release fails badly and FSL Community BSP works fine,
this can be seen in several examples as:

   - use of 3rd-party boards
   - kernel customizability

The Freescale release is tested only for the boards they enumerate in
the Release Notes which comes with the release.

Currently we have 3 vendors which still use 3.0.35 (2 of those -
Congatec and SolidRun - does not have 3.10.17 kernels integrated yet)
and moving to a newer BSP means breaking all previous kernels as the
newer GPU imposes a kernel update. Is it realistic to expect those all
vendors to move to 3.10.31-beta in less than 2 months?

Trustability is something quite difficult to build, but dead easy to
lost. If we release Yocto Project 1.7 with the 3.10.31-beta BSP and it
has a severe issue, we will have a broken release until February - at
best. The community cannot be expected to provide an extended test of
the FSL Community BSP, especially because of the short time before we
need to branch for 1.7 release.

All that said, I vote for Option 1 - conservative.

The possible feedback we, as community, can provide to Freescale I
think won't be decisive for the quality of 3.10.31 release. As you all
can see our bugzilla[1] has feedback entries which are more than one
year[2][3] old and there is no one at Freescale responsible to /fix/
these or comment officially on those.

1. https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=meta-fsl-arm
2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=5098 (opened in
September of 2013)
3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=4510 (opened in
May of 2013)

I hope this makes clear my position. If most of the community prefer
the Option 2 I will accept it, but I think it is not the best choice.

Best Regards,

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Eric Nelson]

Thanks Otavio,

On 08/19/2014 06:59 AM, Otavio Salvador wrote:
> Hello everyone,
> 
> (Included all people who replied in Cc)
> 
> On Mon, Aug 18, 2014 at 12:32 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
>> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
> ...
>> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
>>
>> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>>         o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>>         o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>>         o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
>> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>>         o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>>         o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>>         o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
>>
>> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
> 
> I gave some thought about community feedback regarding these two options.
> 
> First I'd like to analyse the facts about the two options:
> 
> - Option 1 - Conservative option
>    - 3.10.31-beta is merged ASAP in master-next
>    - Yocto Project 1.7 is released with 3.10.17-ga
>    - in October, when we branch 1.7, 3.10.31-beta is merged in master
> 
>    Consequences:
>     - Yocto Project 1.7 has 3.10.17 with GA quality for i.MX6 (with
> all patch released included - 1.0.1, …)
>     - Yocto Project 1.7 has support for the BSP for i.MX6, by FSL
>     - Yocto Project 1.7 is a stable branch with a stable BSP (GA
> quality) for i.MX6
>     - Freescale allow customers to use Yocto Project 1.7 for production
>     - Pre-test of 3.10.31-beta is done in master-next focusing Yocto
> Project 1.8 development cycle
>     - Test of 3.10.310-beta is done in master as soon as Yocto Project
> 1.7 is branched
> 
> - Option 2 - Aggressive option
>    - 3.10.31-beta is merged ASAP in master
>    - Yocto Project 1.7 is released with 3.10.31-bea with Beta quality
>    - Yocto Project 1.7 has 3.10.31 with GA quality merged (expected) in January
> 
>    Consequences:
>     - Yocto Project 1.7 has 3.10.31 with Beta quality for i.MX6
>     - Yocto Project 1.7 DOES NOT has support for the BSP for i.MX6, by FSL
>     - Yocto Project 1.7 is a stable branch with a Beta BSP for i.MX6
>     - Freescale advise customers to use Daisy (Yocto Project 1.6 with
> 3.10.17-ga) for production until 3.10.31-ga is released and merged
> into Yocto Project 1.7 (expected in January)
>     - Pre-test of 3.10.31-beta is done in master until end-September
> as we need to branch for Yocto Project 1.7 release
>     - Test of 3.10.31-beta is done in Yocto Project 1.7 STABLE release
> 
> - Option 3 - Maintain both BSPs around
>    - I deny this as the amount of effort to support and test all this
> would increase my maintainer work and I see no real benefit on this.
> So this is a unfeasible.
> 

This is an interesting personality test.

So far, it sounds as if Otavio and Carlos are the conservative
ones, and Alfonso, Sébastien and I are "aggressive".

> 
> So before I do a clear statement about my preferred option I would
> like to extern some thoughts about what I think it is important to
> ponder when choosing either option.
> 
> Since the creation of FSL Community BSP we (here I include the most
> active contributors in the community) been working in to make the user
> experience as good as possible: code quality, stability and
> flexibility has always been our goals.
> 

Many thanks for this!

> I think we are doing a great job here. I am aware of several examples
> where Freescale release fails badly and FSL Community BSP works fine,
> this can be seen in several examples as:
> 
>    - use of 3rd-party boards
>    - kernel customizability
> 
> The Freescale release is tested only for the boards they enumerate in
> the Release Notes which comes with the release.
> 

Please note that Freescale's Beta testing has been done against
components of Yocto 1.7 if I'm not mistaken, and only against
their kernel sources.

> Currently we have 3 vendors which still use 3.0.35 (2 of those -
> Congatec and SolidRun - does not have 3.10.17 kernels integrated yet)
> and moving to a newer BSP means breaking all previous kernels as the
> newer GPU imposes a kernel update. Is it realistic to expect those all
> vendors to move to 3.10.31-beta in less than 2 months?
> 

The situation is a it messier than that. We also "still use" 3.0.35
kernels for some of our customers, and that's a situation likely to
persist for a long while. I suspect that the same is true for any
vendor doing custom designs or offering SOMs.

The transition to device tree will be a long one.

> Trustability is something quite difficult to build, but dead easy to
> lost. If we release Yocto Project 1.7 with the 3.10.31-beta BSP and it
> has a severe issue, we will have a broken release until February - at
> best. The community cannot be expected to provide an extended test of
> the FSL Community BSP, especially because of the short time before we
> need to branch for 1.7 release.
> 

I think this is the crux of the question: how much weight do you
give to the "-beta" and "-GA" tags?

In my experience, Freescale does a pretty good job of testing
even prior to "-alpha" and "-beta" releases. Without going through
the entire patch sets, my suspicion is that there are more bug
fixes in the 3.10.31 kernel than newly-introduced bugs.

e.g., this PCIe bug fix is present in 3.10.31, but doesn't appear
to be present in 3.10.17_1.0.1:
	http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.31_1.1.0_beta&id=c8a6b97

At this stage, I've not spent much time with 3.10.31, and I've
only used it on Freescale hardware (SABRE SD), and I suspect
that the same is true for others on the list.

> All that said, I vote for Option 1 - conservative.
> 
> The possible feedback we, as community, can provide to Freescale I
> think won't be decisive for the quality of 3.10.31 release. As you all
> can see our bugzilla[1] has feedback entries which are more than one
> year[2][3] old and there is no one at Freescale responsible to /fix/
> these or comment officially on those.
> 
> 1. https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=meta-fsl-arm
> 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=5098 (opened in
> September of 2013)
> 3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=4510 (opened in
> May of 2013)
> 
> I hope this makes clear my position. If most of the community prefer
> the Option 2 I will accept it, but I think it is not the best choice.
> 

I'll re-iterate my preference for Option 2, and I think a key piece of
the equation is Lauren's statement that Freescale's preference is
Option 2.

As always, the key bits are those which we don't control (closed
source binaries), and I suspect that the kernel support for those
is fairly easy to backport to a 3.10.17 kernel if a vendor wants
to stay there.

Back-ports to 3.0.35 will naturally be harder, but we don't solve
this with Option 1 either.

Regards,


Eric

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Carlos Rafael Giani]

Well, of course Freescale is interested in option 2, since it helps with 
their kernel development :)

But think about it this way:
you are a customer, and are using the beta kernel, because that's what 
is in Yocto Project 1.7. Something goes wrong. You contact your 
Freescale FAE. Response: "we can't help you, because you are using an 
unsupported kernel". This is the main problem. Not necessarily the 
stability of the beta kernel, but the lack of Freescale support.


On 2014-08-19 17:55, Eric Nelson wrote:
> Thanks Otavio,
>
> On 08/19/2014 06:59 AM, Otavio Salvador wrote:
>> Hello everyone,
>>
>> (Included all people who replied in Cc)
>>
>> On Mon, Aug 18, 2014 at 12:32 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
>>> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
>> ...
>>> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
>>>
>>> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>>>          o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>>>          o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>>>          o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
>>> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>>>          o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>>>          o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>>>          o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
>>>
>>> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
>> I gave some thought about community feedback regarding these two options.
>>
>> First I'd like to analyse the facts about the two options:
>>
>> - Option 1 - Conservative option
>>     - 3.10.31-beta is merged ASAP in master-next
>>     - Yocto Project 1.7 is released with 3.10.17-ga
>>     - in October, when we branch 1.7, 3.10.31-beta is merged in master
>>
>>     Consequences:
>>      - Yocto Project 1.7 has 3.10.17 with GA quality for i.MX6 (with
>> all patch released included - 1.0.1, …)
>>      - Yocto Project 1.7 has support for the BSP for i.MX6, by FSL
>>      - Yocto Project 1.7 is a stable branch with a stable BSP (GA
>> quality) for i.MX6
>>      - Freescale allow customers to use Yocto Project 1.7 for production
>>      - Pre-test of 3.10.31-beta is done in master-next focusing Yocto
>> Project 1.8 development cycle
>>      - Test of 3.10.310-beta is done in master as soon as Yocto Project
>> 1.7 is branched
>>
>> - Option 2 - Aggressive option
>>     - 3.10.31-beta is merged ASAP in master
>>     - Yocto Project 1.7 is released with 3.10.31-bea with Beta quality
>>     - Yocto Project 1.7 has 3.10.31 with GA quality merged (expected) in January
>>
>>     Consequences:
>>      - Yocto Project 1.7 has 3.10.31 with Beta quality for i.MX6
>>      - Yocto Project 1.7 DOES NOT has support for the BSP for i.MX6, by FSL
>>      - Yocto Project 1.7 is a stable branch with a Beta BSP for i.MX6
>>      - Freescale advise customers to use Daisy (Yocto Project 1.6 with
>> 3.10.17-ga) for production until 3.10.31-ga is released and merged
>> into Yocto Project 1.7 (expected in January)
>>      - Pre-test of 3.10.31-beta is done in master until end-September
>> as we need to branch for Yocto Project 1.7 release
>>      - Test of 3.10.31-beta is done in Yocto Project 1.7 STABLE release
>>
>> - Option 3 - Maintain both BSPs around
>>     - I deny this as the amount of effort to support and test all this
>> would increase my maintainer work and I see no real benefit on this.
>> So this is a unfeasible.
>>
> This is an interesting personality test.
>
> So far, it sounds as if Otavio and Carlos are the conservative
> ones, and Alfonso, Sébastien and I are "aggressive".
>
>> So before I do a clear statement about my preferred option I would
>> like to extern some thoughts about what I think it is important to
>> ponder when choosing either option.
>>
>> Since the creation of FSL Community BSP we (here I include the most
>> active contributors in the community) been working in to make the user
>> experience as good as possible: code quality, stability and
>> flexibility has always been our goals.
>>
> Many thanks for this!
>
>> I think we are doing a great job here. I am aware of several examples
>> where Freescale release fails badly and FSL Community BSP works fine,
>> this can be seen in several examples as:
>>
>>     - use of 3rd-party boards
>>     - kernel customizability
>>
>> The Freescale release is tested only for the boards they enumerate in
>> the Release Notes which comes with the release.
>>
> Please note that Freescale's Beta testing has been done against
> components of Yocto 1.7 if I'm not mistaken, and only against
> their kernel sources.
>
>> Currently we have 3 vendors which still use 3.0.35 (2 of those -
>> Congatec and SolidRun - does not have 3.10.17 kernels integrated yet)
>> and moving to a newer BSP means breaking all previous kernels as the
>> newer GPU imposes a kernel update. Is it realistic to expect those all
>> vendors to move to 3.10.31-beta in less than 2 months?
>>
> The situation is a it messier than that. We also "still use" 3.0.35
> kernels for some of our customers, and that's a situation likely to
> persist for a long while. I suspect that the same is true for any
> vendor doing custom designs or offering SOMs.
>
> The transition to device tree will be a long one.
>
>> Trustability is something quite difficult to build, but dead easy to
>> lost. If we release Yocto Project 1.7 with the 3.10.31-beta BSP and it
>> has a severe issue, we will have a broken release until February - at
>> best. The community cannot be expected to provide an extended test of
>> the FSL Community BSP, especially because of the short time before we
>> need to branch for 1.7 release.
>>
> I think this is the crux of the question: how much weight do you
> give to the "-beta" and "-GA" tags?
>
> In my experience, Freescale does a pretty good job of testing
> even prior to "-alpha" and "-beta" releases. Without going through
> the entire patch sets, my suspicion is that there are more bug
> fixes in the 3.10.31 kernel than newly-introduced bugs.
>
> e.g., this PCIe bug fix is present in 3.10.31, but doesn't appear
> to be present in 3.10.17_1.0.1:
> 	http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.31_1.1.0_beta&id=c8a6b97
>
> At this stage, I've not spent much time with 3.10.31, and I've
> only used it on Freescale hardware (SABRE SD), and I suspect
> that the same is true for others on the list.
>
>> All that said, I vote for Option 1 - conservative.
>>
>> The possible feedback we, as community, can provide to Freescale I
>> think won't be decisive for the quality of 3.10.31 release. As you all
>> can see our bugzilla[1] has feedback entries which are more than one
>> year[2][3] old and there is no one at Freescale responsible to /fix/
>> these or comment officially on those.
>>
>> 1. https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=meta-fsl-arm
>> 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=5098 (opened in
>> September of 2013)
>> 3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=4510 (opened in
>> May of 2013)
>>
>> I hope this makes clear my position. If most of the community prefer
>> the Option 2 I will accept it, but I think it is not the best choice.
>>
> I'll re-iterate my preference for Option 2, and I think a key piece of
> the equation is Lauren's statement that Freescale's preference is
> Option 2.
>
> As always, the key bits are those which we don't control (closed
> source binaries), and I suspect that the kernel support for those
> is fairly easy to backport to a 3.10.17 kernel if a vendor wants
> to stay there.
>
> Back-ports to 3.0.35 will naturally be harder, but we don't solve
> this with Option 1 either.
>
> Regards,
>
>
> Eric

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Eric Nelson]

Hi Otavio,

On 08/19/2014 09:01 AM, Carlos Rafael Giani wrote:
> Well, of course Freescale is interested in option 2, since it helps with
> their kernel development :)
> 

Which is a good thing!

> But think about it this way:
>
> you are a customer, and are using the beta kernel, because that's what
> is in Yocto Project 1.7. Something goes wrong. You contact your
> Freescale FAE. Response: "we can't help you, because you are using an
> unsupported kernel". This is the main problem. Not necessarily the
> stability of the beta kernel, but the lack of Freescale support.
>

My experience is that getting support on the latest is easier, since
that's where developers tend to live.

When Freescale is asked to investigate a bug, they will likely ask
that it be reproduced on Freescale hardware and using a Freescale
supplied kernel and userspace (i.e. not from the Community BSP).

For users of other hardware and kernels (i.e. most of the world), these
tend to be the biggest hurdles.

By placing the latest (-beta) kernel in master-next now and
master in October, we're placing a big hurdle on adoption of
3.10.31. Breakage is common in master and this generally has
nothing to do with the kernel or Freescale bits.

This is clearly all gray area, and these are just my 2c.

Regards,


Eric

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Otavio Salvador]

On Tue, Aug 19, 2014 at 1:22 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> On 08/19/2014 09:01 AM, Carlos Rafael Giani wrote:
>> Well, of course Freescale is interested in option 2, since it helps with
>> their kernel development :)
>>
>
> Which is a good thing!
>
>> But think about it this way:
>>
>> you are a customer, and are using the beta kernel, because that's what
>> is in Yocto Project 1.7. Something goes wrong. You contact your
>> Freescale FAE. Response: "we can't help you, because you are using an
>> unsupported kernel". This is the main problem. Not necessarily the
>> stability of the beta kernel, but the lack of Freescale support.
>>
>
> My experience is that getting support on the latest is easier, since
> that's where developers tend to live.
>
> When Freescale is asked to investigate a bug, they will likely ask
> that it be reproduced on Freescale hardware and using a Freescale
> supplied kernel and userspace (i.e. not from the Community BSP).
>
> For users of other hardware and kernels (i.e. most of the world), these
> tend to be the biggest hurdles.
>
> By placing the latest (-beta) kernel in master-next now and
> master in October, we're placing a big hurdle on adoption of
> 3.10.31. Breakage is common in master and this generally has
> nothing to do with the kernel or Freescale bits.
>
> This is clearly all gray area, and these are just my 2c.

Just to clarify.

What should we do with boards which:

a) including in master now means getting 3.10.31 in next stable, in October.
b) does not update or fix their kernel to work with newer GPU stack?

b is very critical in my point of view as this impacts user experience
and if we don't remove broken boards their images will segfault in the
boards.

What is your view on this?


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Otavio Salvador]

On Tue, Aug 19, 2014 at 12:55 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Thanks Otavio,
>
> On 08/19/2014 06:59 AM, Otavio Salvador wrote:
>> Hello everyone,
>>
>> (Included all people who replied in Cc)
>>
>> On Mon, Aug 18, 2014 at 12:32 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
>>> Our 3.10.31-1.1.0 Beta release is now in field trial to be completed by next week.  My team will be up-streaming this release next week into master-next branch.
>> ...
>>> We have a question to community.  Our 3.10.31-1.1.0 GA release is not public/released until January.   We have two options for upstream of 3.10.31 into meta-fsl-arm and would like feedback from community.
>>>
>>> - Option 1 - Upstream 3.10.31 beta into master-next branch and branch master with 3.10.17 once Yocto Project 1.7 name is announced in late Sept or early October
>>>         o   This means that 3.10.31-1.1.0_beta will be in master-next branch during September.
>>>         o   Also means Freescale will get less feedback from community to fix for our 3.10.31-1.1.0 GA release.
>>>         o   3.10.31-1.1.0 GA will be part of Yocto Project 1.8 release only in April 2015.
>>> - Option 2 - Upstream 3.10.31-1.1.0 Beta into master branch and remove 3.10.17 from master branch.
>>>         o   This means Yocto Project 1.7 release will not be production code for i.MX6 until our 3.10.31-1.1.0 GA release planned in January.
>>>         o   Allows earlier production release of 3.10.31-1.1.0 GA with SoloX and Graphics as part of Yocto Project 1.7 in January.
>>>         o   Beta is not supported (by freescale/for production/by SR).  However bugs can be sent to imx-community and if time before GA code freeze Freescale can try to fix in our GA release.
>>>
>>> Please provide your feedback.  Freescale prefers Option 2 because we can get more feedback about bugs to fix in our 3.10.31-1.1.0 GA release but we will abide by community wishes if they prefer Option 1.
>>
>> I gave some thought about community feedback regarding these two options.
>>
>> First I'd like to analyse the facts about the two options:
>>
>> - Option 1 - Conservative option
>>    - 3.10.31-beta is merged ASAP in master-next
>>    - Yocto Project 1.7 is released with 3.10.17-ga
>>    - in October, when we branch 1.7, 3.10.31-beta is merged in master
>>
>>    Consequences:
>>     - Yocto Project 1.7 has 3.10.17 with GA quality for i.MX6 (with
>> all patch released included - 1.0.1, …)
>>     - Yocto Project 1.7 has support for the BSP for i.MX6, by FSL
>>     - Yocto Project 1.7 is a stable branch with a stable BSP (GA
>> quality) for i.MX6
>>     - Freescale allow customers to use Yocto Project 1.7 for production
>>     - Pre-test of 3.10.31-beta is done in master-next focusing Yocto
>> Project 1.8 development cycle
>>     - Test of 3.10.310-beta is done in master as soon as Yocto Project
>> 1.7 is branched
>>
>> - Option 2 - Aggressive option
>>    - 3.10.31-beta is merged ASAP in master
>>    - Yocto Project 1.7 is released with 3.10.31-bea with Beta quality
>>    - Yocto Project 1.7 has 3.10.31 with GA quality merged (expected) in January
>>
>>    Consequences:
>>     - Yocto Project 1.7 has 3.10.31 with Beta quality for i.MX6
>>     - Yocto Project 1.7 DOES NOT has support for the BSP for i.MX6, by FSL
>>     - Yocto Project 1.7 is a stable branch with a Beta BSP for i.MX6
>>     - Freescale advise customers to use Daisy (Yocto Project 1.6 with
>> 3.10.17-ga) for production until 3.10.31-ga is released and merged
>> into Yocto Project 1.7 (expected in January)
>>     - Pre-test of 3.10.31-beta is done in master until end-September
>> as we need to branch for Yocto Project 1.7 release
>>     - Test of 3.10.31-beta is done in Yocto Project 1.7 STABLE release
>>
>> - Option 3 - Maintain both BSPs around
>>    - I deny this as the amount of effort to support and test all this
>> would increase my maintainer work and I see no real benefit on this.
>> So this is a unfeasible.
>>
>
> This is an interesting personality test.
>
> So far, it sounds as if Otavio and Carlos are the conservative
> ones, and Alfonso, Sébastien and I are "aggressive".

I am sure you didn't take this to the personal side, but for clearness
I am not talking about personality but the way we will handle
transitions.

...
>> I think we are doing a great job here. I am aware of several examples
>> where Freescale release fails badly and FSL Community BSP works fine,
>> this can be seen in several examples as:
>>
>>    - use of 3rd-party boards
>>    - kernel customizability
>>
>> The Freescale release is tested only for the boards they enumerate in
>> the Release Notes which comes with the release.
>>
>
> Please note that Freescale's Beta testing has been done against
> components of Yocto 1.7 if I'm not mistaken, and only against
> their kernel sources.

Are you sure?

http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/log/?h=daisy_3.10.31-1.1.0_beta

So no. They are not doing extensive test on top of upcoming 1.7.

>> Currently we have 3 vendors which still use 3.0.35 (2 of those -
>> Congatec and SolidRun - does not have 3.10.17 kernels integrated yet)
>> and moving to a newer BSP means breaking all previous kernels as the
>> newer GPU imposes a kernel update. Is it realistic to expect those all
>> vendors to move to 3.10.31-beta in less than 2 months?
>
> The situation is a it messier than that. We also "still use" 3.0.35
> kernels for some of our customers, and that's a situation likely to
> persist for a long while. I suspect that the same is true for any
> vendor doing custom designs or offering SOMs.
>
> The transition to device tree will be a long one.

Great; how are you going to do with 3.0.35 users in 1.7 if we go with newer GPU?

It seems some vendors are finishing their update to 3.10.17 (I know
about Congatec, which sent an initial patch this week, and other
vendors which didn't send patches yet). Expecting they to jump to a
new kernel and GPU in less of a month is not realistic.

>> Trustability is something quite difficult to build, but dead easy to
>> lost. If we release Yocto Project 1.7 with the 3.10.31-beta BSP and it
>> has a severe issue, we will have a broken release until February - at
>> best. The community cannot be expected to provide an extended test of
>> the FSL Community BSP, especially because of the short time before we
>> need to branch for 1.7 release.
>
> I think this is the crux of the question: how much weight do you
> give to the "-beta" and "-GA" tags?
>
> In my experience, Freescale does a pretty good job of testing
> even prior to "-alpha" and "-beta" releases. Without going through
> the entire patch sets, my suspicion is that there are more bug
> fixes in the 3.10.31 kernel than newly-introduced bugs.
>
> e.g., this PCIe bug fix is present in 3.10.31, but doesn't appear
> to be present in 3.10.17_1.0.1:
>         http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.31_1.1.0_beta&id=c8a6b97
>
> At this stage, I've not spent much time with 3.10.31, and I've
> only used it on Freescale hardware (SABRE SD), and I suspect
> that the same is true for others on the list.

Agreed; the point is Freescale won't provide support in case of issues
and any fixes will need to wait until GA goes out.

About backporting fixes I fully agree Freescale ought to be more
active in including fixes in their GA kernel while doing the next-BSP
development. I hope this improves in mid/long term.

>> All that said, I vote for Option 1 - conservative.
>>
>> The possible feedback we, as community, can provide to Freescale I
>> think won't be decisive for the quality of 3.10.31 release. As you all
>> can see our bugzilla[1] has feedback entries which are more than one
>> year[2][3] old and there is no one at Freescale responsible to /fix/
>> these or comment officially on those.
>>
>> 1. https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=meta-fsl-arm
>> 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=5098 (opened in
>> September of 2013)
>> 3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=4510 (opened in
>> May of 2013)
>>
>> I hope this makes clear my position. If most of the community prefer
>> the Option 2 I will accept it, but I think it is not the best choice.
>>
>
> I'll re-iterate my preference for Option 2, and I think a key piece of
> the equation is Lauren's statement that Freescale's preference is
> Option 2.
>
> As always, the key bits are those which we don't control (closed
> source binaries), and I suspect that the kernel support for those
> is fairly easy to backport to a 3.10.17 kernel if a vendor wants
> to stay there.

Should be.

> Back-ports to 3.0.35 will naturally be harder, but we don't solve
> this with Option 1 either.

3.0.35 should be easy to update to kernel GPU, if you look at their Git:

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.1.0&id=5e5f0d6d0d9c022c93e4a8c3680b682e2b8f6b4f

So vendors wishing to use 3.0.35 with 3.10.17 GPU is very possible.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Eric Nelson]

Hi Otavio,

On 08/19/2014 10:21 AM, Otavio Salvador wrote:
> On Tue, Aug 19, 2014 at 1:22 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> On 08/19/2014 09:01 AM, Carlos Rafael Giani wrote:
>>> Well, of course Freescale is interested in option 2, since it helps with
>>> their kernel development :)
>>>
>>
>> Which is a good thing!
>>
>>> But think about it this way:
>>>
>>> you are a customer, and are using the beta kernel, because that's what
>>> is in Yocto Project 1.7. Something goes wrong. You contact your
>>> Freescale FAE. Response: "we can't help you, because you are using an
>>> unsupported kernel". This is the main problem. Not necessarily the
>>> stability of the beta kernel, but the lack of Freescale support.
>>>
>>
>> My experience is that getting support on the latest is easier, since
>> that's where developers tend to live.
>>
>> When Freescale is asked to investigate a bug, they will likely ask
>> that it be reproduced on Freescale hardware and using a Freescale
>> supplied kernel and userspace (i.e. not from the Community BSP).
>>
>> For users of other hardware and kernels (i.e. most of the world), these
>> tend to be the biggest hurdles.
>>
>> By placing the latest (-beta) kernel in master-next now and
>> master in October, we're placing a big hurdle on adoption of
>> 3.10.31. Breakage is common in master and this generally has
>> nothing to do with the kernel or Freescale bits.
>>
>> This is clearly all gray area, and these are just my 2c.
> 
> Just to clarify.
> 
> What should we do with boards which:
> 
> a) including in master now means getting 3.10.31 in next stable, in October.
> b) does not update or fix their kernel to work with newer GPU stack?
> 
> b is very critical in my point of view as this impacts user experience
> and if we don't remove broken boards their images will segfault in the
> boards.
> 
> What is your view on this?
> 

Let 'em use Dora or Daisy.

While I'm pulling for the aggressive option in the Community BSP,
many of our customers will (and should be) very conservative, and
we'll work with them to decide whether they want to back-port updates
to the kernel or other packages to their build.

The Community BSP should not be viewed as a production distribution.
It's purpose should be to provide an easy on-ramp for new users and
avenue for pushing things forward.

Before shipping product, versions should be locked down as is done
in the Freescale "official" releases.

Regards,


Eric

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Eric Nelson]

Hi Otavio,

On 08/19/2014 10:24 AM, Otavio Salvador wrote:
> On Tue, Aug 19, 2014 at 12:55 PM, Eric Nelson
>> Thanks Otavio,
>>
>> On 08/19/2014 06:59 AM, Otavio Salvador wrote:
>>> Hello everyone,
>>>
>>> <snip>
>>>
>>> I think we are doing a great job here. I am aware of several examples
>>> where Freescale release fails badly and FSL Community BSP works fine,
>>> this can be seen in several examples as:
>>>
>>>    - use of 3rd-party boards
>>>    - kernel customizability
>>>
>>> The Freescale release is tested only for the boards they enumerate in
>>> the Release Notes which comes with the release.
>>>
>>
>> Please note that Freescale's Beta testing has been done against
>> components of Yocto 1.7 if I'm not mistaken, and only against
>> their kernel sources.
> 
> Are you sure?
> 
> http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/log/?h=daisy_3.10.31-1.1.0_beta
> 
> So no. They are not doing extensive test on top of upcoming 1.7.
> 

This isn't the first time I've been wrong!

>>> Currently we have 3 vendors which still use 3.0.35 (2 of those -
>>> Congatec and SolidRun - does not have 3.10.17 kernels integrated yet)
>>> and moving to a newer BSP means breaking all previous kernels as the
>>> newer GPU imposes a kernel update. Is it realistic to expect those all
>>> vendors to move to 3.10.31-beta in less than 2 months?
>>
>> The situation is a it messier than that. We also "still use" 3.0.35
>> kernels for some of our customers, and that's a situation likely to
>> persist for a long while. I suspect that the same is true for any
>> vendor doing custom designs or offering SOMs.
>>
>> The transition to device tree will be a long one.
> 
> Great; how are you going to do with 3.0.35 users in 1.7 if 
> we go with newer GPU?
> 

Customers will be reluctant (and slow) to move to 1.7 for the same
reason as with moving from one kernel to the next. Full regression
testing takes time, and most of our customers will only do this
annually or semi-annually, driven by features and bug fixes.

>
> It seems some vendors are finishing their update to 3.10.17 (I know
> about Congatec, which sent an initial patch this week, and other
> vendors which didn't send patches yet). Expecting they to jump to a
> new kernel and GPU in less of a month is not realistic.
>

1.6 isn't going away when 1.7 arrives, so it's not as if this is
a hard deadline.

The 3.10.17 -> 3.10.31 jump will also be much easier than 3.0.35->3.10.

>>> Trustability is something quite difficult to build, but dead easy to
>>> lost. If we release Yocto Project 1.7 with the 3.10.31-beta BSP and it
>>> has a severe issue, we will have a broken release until February - at
>>> best. The community cannot be expected to provide an extended test of
>>> the FSL Community BSP, especially because of the short time before we
>>> need to branch for 1.7 release.
>>
>> I think this is the crux of the question: how much weight do you
>> give to the "-beta" and "-GA" tags?
>>
>> In my experience, Freescale does a pretty good job of testing
>> even prior to "-alpha" and "-beta" releases. Without going through
>> the entire patch sets, my suspicion is that there are more bug
>> fixes in the 3.10.31 kernel than newly-introduced bugs.
>>
>> e.g., this PCIe bug fix is present in 3.10.31, but doesn't appear
>> to be present in 3.10.17_1.0.1:
>>         http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.31_1.1.0_beta&id=c8a6b97
>>
>> At this stage, I've not spent much time with 3.10.31, and I've
>> only used it on Freescale hardware (SABRE SD), and I suspect
>> that the same is true for others on the list.
> 
> Agreed; the point is Freescale won't provide support in case of issues
> and any fixes will need to wait until GA goes out.
> 
> About backporting fixes I fully agree Freescale ought to be more
> active in including fixes in their GA kernel while doing the next-BSP
> development. I hope this improves in mid/long term.
> 

In many ways, I think we lose a lot when we talk of Freescale kernel
versions here. It seems more to the point to discuss ABI versions
for the closed-source packages, and those are the bits that I'm
particularly interested in pushing forward, since there have been
many bug fixes and enhancements in the latest releases (see Lauren's
list).

>>> All that said, I vote for Option 1 - conservative.
>>>
>>> The possible feedback we, as community, can provide to Freescale I
>>> think won't be decisive for the quality of 3.10.31 release. As you all
>>> can see our bugzilla[1] has feedback entries which are more than one
>>> year[2][3] old and there is no one at Freescale responsible to /fix/
>>> these or comment officially on those.
>>>
>>> 1. https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=meta-fsl-arm
>>> 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=5098 (opened in
>>> September of 2013)
>>> 3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=4510 (opened in
>>> May of 2013)
>>>
>>> I hope this makes clear my position. If most of the community prefer
>>> the Option 2 I will accept it, but I think it is not the best choice.
>>>
>>
>> I'll re-iterate my preference for Option 2, and I think a key piece of
>> the equation is Lauren's statement that Freescale's preference is
>> Option 2.
>>
>> As always, the key bits are those which we don't control (closed
>> source binaries), and I suspect that the kernel support for those
>> is fairly easy to backport to a 3.10.17 kernel if a vendor wants
>> to stay there.
> 
> Should be.
> 
>> Back-ports to 3.0.35 will naturally be harder, but we don't solve
>> this with Option 1 either.
> 
> 3.0.35 should be easy to update to kernel GPU, if you look at their Git:
> 
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.1.0&id=5e5f0d6d0d9c022c93e4a8c3680b682e2b8f6b4f
> 
> So vendors wishing to use 3.0.35 with 3.10.17 GPU is very possible.
> 

;) See what I mean? You're referring to "3.10.17 GPU" instead of
a GPU version. IMHO, it would be best if these had independent
version references.

To your point about 3.0.35 and the 3.10.17 GPU binaries, I suspect that
the same is true of the 3.10.31 binaries.

Regards,


Eric

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Lauren Post]

Keeping this short to make it easier to read.  Below are my thoughts in responses to the other comments on this thread.

- 3.10.31-1.1.0_Beta is released on top of Daisy 1.6.  Our process is to build and test on top of the last Yocto Project release.  Our GA release will also be based on Daisy because our code freeze for GA is too close to the Yocto Project release for 1.7 to make the upgrade. 

- 3.10.31 is 3.10.17 plus fixes for existing i.mx6 hardware (but there is new graphics update that is not GA quality)

- i.MX6 SoloX is a new hardware which is still beta quality and only supported in 3.10.31 (will not be backported) 

- Soon 3.10.17 and 3.10.31 graphics will be  independent from kernel and would be able to be mixed with each kernel  meaning you could use 3.10.31 kernel with v4 graphics (3.10.17) 

- Eric's point about upgraded proprietary packages is a good one in that our next chance to update them will only be the 3.10.31 GA release so bugs reported earlier help us get these fixed for GA. 

- There is a higher chance of getting bugs fixed NOW for GA then after GA. Please submit bugs via bugzilla and forward me so I can forward to the teams to investigate. 

- Everything for 3.10.31-1.1.0_beta is public on our external git - http://git.freescale.com/ and you can  build using our release layer on top of daisy http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.31-1.1.0_beta  Try it before making a final decision.   Our patches will not be upstreamed until after our field trial concludes this week.   

Lauren Post
Yocto Project i.MX Team Lead

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Otavio Salvador]

Hello folks,

On Tue, Aug 19, 2014 at 4:23 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
...
> - Soon 3.10.17 and 3.10.31 graphics will be  independent from kernel and would be able to be mixed with each kernel  meaning you could use 3.10.31 kernel with v4 graphics (3.10.17)

This is a great step in the right direction. So this alleviate part of
the trouble we have across vendors. So is it going to be done for the
3.10.31 GA? or still for the Beta?

What about the VPU? Is 3.10.31 VPU packages compatible with 3.10.17?

> - Eric's point about upgraded proprietary packages is a good one in that our next chance to update them will only be the 3.10.31 GA release so bugs reported earlier help us get these fixed for GA.

Eric concern, in my understanding, is about the ABI between the binary
blobs and the compatibility against kernel releases.

What has changed? What is needed to backport?

> - There is a higher chance of getting bugs fixed NOW for GA then after GA. Please submit bugs via bugzilla and forward me so I can forward to the teams to investigate.

Please subscribe to the Bugzilla so I can assign the current issues to
your account. This easy tracking of reported issues.

> - Everything for 3.10.31-1.1.0_beta is public on our external git - http://git.freescale.com/ and you can  build using our release layer on top of daisy http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.31-1.1.0_beta  Try it before making a final decision.   Our patches will not be upstreamed until after our field trial concludes this week.

So folks, one question remain open:

Considering we go with option 2, as seem most people prefer, what to
do regarding the non-updated boards in meta-fsl-arm-extra?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Eric Bénard]

Hi Otavio,

Le Tue, 19 Aug 2014 17:00:23 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :
> So folks, one question remain open:
> 
> Considering we go with option 2, as seem most people prefer, what to
> do regarding the non-updated boards in meta-fsl-arm-extra?
> 
simply drop them and let vendors upgrade the support later if their
customers ask for it.
There is no reason for meta-fsl-arm-extra to block meta-fsl-arm because
a vendor pushed a board one time ago expecting community will maintain
it for ever.

Best regards,
Eric

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[John Weber]

Hi Otavio,

On 8/19/14, 3:00 PM, Otavio Salvador wrote:
> Hello folks,
>
> On Tue, Aug 19, 2014 at 4:23 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
> ...
>> - Soon 3.10.17 and 3.10.31 graphics will be  independent from kernel and would be able to be mixed with each kernel  meaning you could use 3.10.31 kernel with v4 graphics (3.10.17)
> This is a great step in the right direction. So this alleviate part of
> the trouble we have across vendors. So is it going to be done for the
> 3.10.31 GA? or still for the Beta?
>
> What about the VPU? Is 3.10.31 VPU packages compatible with 3.10.17?
>
>> - Eric's point about upgraded proprietary packages is a good one in that our next chance to update them will only be the 3.10.31 GA release so bugs reported earlier help us get these fixed for GA.
> Eric concern, in my understanding, is about the ABI between the binary
> blobs and the compatibility against kernel releases.
>
> What has changed? What is needed to backport?
>
>> - There is a higher chance of getting bugs fixed NOW for GA then after GA. Please submit bugs via bugzilla and forward me so I can forward to the teams to investigate.
> Please subscribe to the Bugzilla so I can assign the current issues to
> your account. This easy tracking of reported issues.
>
>> - Everything for 3.10.31-1.1.0_beta is public on our external git - http://git.freescale.com/ and you can  build using our release layer on top of daisy http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.31-1.1.0_beta  Try it before making a final decision.   Our patches will not be upstreamed until after our field trial concludes this week.
> So folks, one question remain open:
>
> Considering we go with option 2, as seem most people prefer, what to
> do regarding the non-updated boards in meta-fsl-arm-extra?
>
I am for Option 1, though I see Lauren's point concerning the chances of getting 
bugs fixed before the release of GA if the kernels are being adopted and tested 
by the community prior to release.  I think this will happen as a matter of 
course if improvements are made.  Let developers work with master-next if they 
want to work with 3.10.31.

I only think that a handful of -extra boards adopting 3.10.31, those currently 
supporting 3.10.17, before 1.7 lockdown.  If updates to the proprietary packages 
break 3.10.17, you'll get a lot of broken machines in the stable release, with a 
kernel that is beta quality.

One comment on the relative quality of beta vs. GA releases.  I found that 
3.10.17_beta had a number of issues that were fixed in GA.  Just my experience.

John

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Daiane Angolini]

I think a lot has been said, and I agree with arguments from both
sides. I´ve been talking to Otavio and Lauren directly as well, and I
decided to be the last one to say something.

As community, we must think about ourselves, what are the guidelines
that (hum) guides us. And I´ve been trying to factor the most
important goals we would have. I don´t know if it´s right or complete,
but I made my list:

* stable branch is stable
* we are part of Yocto Project

We are part of Yocto Project. Freescale release/layer is not part of
Yocto Project. meta-fsl-bsp-release does not need to follow the Yocto
Project release schedule. We do.

I remember this is not the first time we discuss how stable should we
keep our next stable branch with the price of having the latest. And,
I don´t think this is the last.

One can say we must decide each release, case by case. However, I
don´t want to spend my time again talking about this again next
release. Again. For me, it´s clear that Freescale not being part of
Yocto Project is what causes this mismatch of release dates, and until
they realize we follow YP release timing, we will keep spending time
in the same discussion. I really prefer chocolate cake, seriously.

Otavio, I think everyone gave the 2 cents needed. We have already
money for a coxinha here. With my 2 cents we can buy the refri and
make a party. Can you, please, start a new clean thread for us to
formalize the votes and count it precisely? (only votes, please, more
arguments can be shared in this thread)

I formalize my vote there.


Please, let me know what you think.

Daiane

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Sébastien Taylor]

On Aug 19, 2014, at 2:00 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:

> Hello folks,
> 
> On Tue, Aug 19, 2014 at 4:23 PM, Lauren Post <Lauren.Post@freescale.com> wrote:
> ...
>> - Soon 3.10.17 and 3.10.31 graphics will be  independent from kernel and would be able to be mixed with each kernel  meaning you could use 3.10.31 kernel with v4 graphics (3.10.17)
> 
> This is a great step in the right direction. So this alleviate part of
> the trouble we have across vendors. So is it going to be done for the
> 3.10.31 GA? or still for the Beta?
> 
> What about the VPU? Is 3.10.31 VPU packages compatible with 3.10.17?
> 

To me this is the biggest push for 3.10.31.  GPU driver/library updates are few and far between, and are badly needed.  Keeping the two separate would make it easier to pull in GPU updates without having to do the full kernel updates.

As a bonus, RELEASE NOTES for GPU driver/library updates would be greatly appreciated.

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Alexander Holler]

Am 18.08.2014 17:32, schrieb Lauren Post:

Hello,

I'm new to i.MX6 and don't use yocto, so pelase forgive me if I ask a 
maybe stupid question.

> 	-  Kernel upgrade to 3.10.31

3.10.y is already at 3.10.52. Is there any reason why the current stable
version of the longterm 3.10.y branch isn't used as a base?

Because I've run into a problem with 3.10.17 which was fixed with
v3.10.22 (december last year) I've recently rebased those 1200+ patches
myself on top of 3.10.52, without any problems (took me around 15
minutes to solve 3 conflicts, testing excluded). So merging the current
stable version of 3.10.y, if prefered, should be equally easy.

My understanding of the stable trees is that they are especially used to 
provide security fixes (besides bugfixes). So I don't really understand 
why about 20 minor releases of maybe import fixes are ignored.

Regards,

Alexander Holler

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Lauren Post]

Our policy is to be at LTSI kernel which is 3.10.31  http://ltsi.linuxfoundation.org/ 

-----Original Message-----
From: Alexander Holler [mailto:holler@ahsoftware.de] 
Sent: Wednesday, August 20, 2014 5:54 PM
To: Post Lauren-RAA013; meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] i.MX 3.10.31-1.1.0_beta release - community feedback requested

Am 18.08.2014 17:32, schrieb Lauren Post:

Hello,

I'm new to i.MX6 and don't use yocto, so pelase forgive me if I ask a maybe stupid question.

> 	-  Kernel upgrade to 3.10.31

3.10.y is already at 3.10.52. Is there any reason why the current stable version of the longterm 3.10.y branch isn't used as a base?

Because I've run into a problem with 3.10.17 which was fixed with
v3.10.22 (december last year) I've recently rebased those 1200+ patches myself on top of 3.10.52, without any problems (took me around 15 minutes to solve 3 conflicts, testing excluded). So merging the current stable version of 3.10.y, if prefered, should be equally easy.

My understanding of the stable trees is that they are especially used to provide security fixes (besides bugfixes). So I don't really understand why about 20 minor releases of maybe import fixes are ignored.

Regards,

Alexander Holler

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Alexander Holler]

Am 21.08.2014 01:04, schrieb Lauren Post:
> Our policy is to be at LTSI kernel which is 3.10.31  http://ltsi.linuxfoundation.org/

Oh, another longterm stable tree. Thanks for enlighten me.

>
> -----Original Message-----
> From: Alexander Holler [mailto:holler@ahsoftware.de]
> Sent: Wednesday, August 20, 2014 5:54 PM
> To: Post Lauren-RAA013; meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] i.MX 3.10.31-1.1.0_beta release - community feedback requested
>
> Am 18.08.2014 17:32, schrieb Lauren Post:
>
> Hello,
>
> I'm new to i.MX6 and don't use yocto, so pelase forgive me if I ask a maybe stupid question.
>
>> 	-  Kernel upgrade to 3.10.31
>
> 3.10.y is already at 3.10.52. Is there any reason why the current stable version of the longterm 3.10.y branch isn't used as a base?
>
> Because I've run into a problem with 3.10.17 which was fixed with
> v3.10.22 (december last year) I've recently rebased those 1200+ patches myself on top of 3.10.52, without any problems (took me around 15 minutes to solve 3 conflicts, testing excluded). So merging the current stable version of 3.10.y, if prefered, should be equally easy.
>
> My understanding of the stable trees is that they are especially used to provide security fixes (besides bugfixes). So I don't really understand why about 20 minor releases of maybe import fixes are ignored.
>
> Regards,
>
> Alexander Holler
>

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[xxiao8]

Just switched from digest mode to single email mode and waiting for 
whoever does the next vote, then I will have the thread to vote on...

xxiao

On 08/20/2014 02:41 PM, Otavio Salvador wrote:
> On Wed, Aug 20, 2014 at 3:12 PM, xxiao8 <xxiao8@fosiao.com> wrote:
>> I would have hoped Freescale stuck with 3.10.17 instead of 3.10.31 to make
>> 3.10.17 solid in the first place, unless 3.10.31 brought in something that
>> is a must-to-have I don't see the reason to make things unnecessarily
>> complicated. Customer can always patch to whatever 3.10.x when they want to
>> as those incremental patches are normally independent of Freescale's code
>> changes. Not to mention nowadays it's 3.10.53 now.
>>
>> Backport 3.10.31-beta to 3.10.17 and make this a gold release kernel is the
>> best option in my opinion. I again don't see the point to diverge at all.
> Please, if you want your vote to be considered do it in the another
> thread and inform your full name (as your name is not in from).
>

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[Otavio Salvador]

On Wed, Aug 20, 2014 at 3:12 PM, xxiao8 <xxiao8@fosiao.com> wrote:
> I would have hoped Freescale stuck with 3.10.17 instead of 3.10.31 to make
> 3.10.17 solid in the first place, unless 3.10.31 brought in something that
> is a must-to-have I don't see the reason to make things unnecessarily
> complicated. Customer can always patch to whatever 3.10.x when they want to
> as those incremental patches are normally independent of Freescale's code
> changes. Not to mention nowadays it's 3.10.53 now.
>
> Backport 3.10.31-beta to 3.10.17 and make this a gold release kernel is the
> best option in my opinion. I again don't see the point to diverge at all.

Please, if you want your vote to be considered do it in the another
thread and inform your full name (as your name is not in from).

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: i.MX 3.10.31-1.1.0_beta release - community feedback requested

[xxiao8]

I would have hoped Freescale stuck with 3.10.17 instead of 3.10.31 to 
make 3.10.17 solid in the first place, unless 3.10.31 brought in 
something that is a must-to-have I don't see the reason to make things 
unnecessarily complicated. Customer can always patch to whatever 3.10.x 
when they want to as those incremental patches are normally independent 
of Freescale's code changes. Not to mention nowadays it's 3.10.53 now.

Backport 3.10.31-beta to 3.10.17 and make this a gold release kernel is 
the best option in my opinion. I again don't see the point to diverge at 
all.

xxiao