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

[Eric Nelson <eric.nelson@boundarydevices.com>]

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