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

[Otavio Salvador <otavio@ossystems.com.br>]

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