[meta-freescale] [meta-fsl-arm-extra][PATCH] nitrogen6x.conf: Allow kernel provider override

[Gary Thomas]

On 2013-10-30 11:46, Eric Nelson wrote:
> Hi Otavio,
>
> On 10/30/2013 10:29 AM, Otavio Salvador wrote:
>> On Wed, Oct 30, 2013 at 2:56 PM, Daiane Angolini <daiane.list at gmail.com> wrote:
>>> On Wed, Oct 30, 2013 at 2:01 PM, Otavio Salvador
>>> <otavio at ossystems.com.br> wrote:
>>>> On Wed, Oct 30, 2013 at 12:44 PM, Gary Thomas <gary at mlbassoc.com> wrote:
>>>>> On 2013-10-30 08:33, Otavio Salvador wrote:
>>>>>> On Wed, Oct 30, 2013 at 12:25 PM, Gary Thomas <gary at mlbassoc.com> wrote:
>>>>>>> On 2013-10-30 08:10, Otavio Salvador wrote:
>>>>>>>> On Wed, Oct 30, 2013 at 11:41 AM, Gary Thomas <gary at mlbassoc.com> wrote:
>>>>>>>>>
>>>>>>>>> This change lets the user override the choice of kernel in local.conf
>>>>>>>>> Without it, there is no way to build any kernel, e.g. linux-imx, other
>>>>>>>>> than the linux-boundary version.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Gary Thomas <gary at mlbassoc.com>
>>>>>>>>
>>>
>>> <snip>
>>>
>>> I do agree with both sides. But I think you didn´t presented the
>>> complete set of possibilities. I mean, it´s not a "support" X
>>> "flexibility" fight.
>>>
>>> If nitrogen-any deserves to be flexible, so all other deserves it the same way.
>>>
>>> If it´s "wrong" for one board. It´s "wrong" for any. So, please submit
>>> the patch to fix all/every board.
>>
>> Agreed here.
>>
> Works for me.
>
> Gary, do you want to take the patch? Otavio asked me 'cause he
> was asking about our board...

Sure, I'll take this on for all the boards in meta-fsl-arm-*  Look for
it later today or tomorrow.

>
>>> As I really don´t have an strong position for this. I would say, let´s
>>> change and see what´s happens.
>>>
>>> For support nightmare, we always need to say what is
>>> u-boot/kernel/yocto problem in this ML, so the nightmare is already
>>> here.
>>
>> :-(
>>
>
> Aww, it's not a nightmare. It's a jobs program ;)
>
>>> But, in my opinion, it´s NOT a bug fix, and should NOT be merged in dora.
>>
>> Yes I agree it is not a bugfix but I think that it'd be better to be
>> consistent with dora and master at this point. Most people will keep
>> using dora for a while and it'd be better to have this deplyed now
>> than see how it goes in 1.6 only.
>>
>> Comments?
>>
>
> Gary, did you ever think a single question mark would prompt so much
> discussion?

Not unlike the recent headline "Single bit error in Toyota firmware kills ..."

>
> I wish we had a clean "MAKEALL" to make sure nothing breaks, but that
> seems unlikely.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------