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 <[email protected]> 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
