[linux-yocto] [PATCH v2 0/4][3.10][meta] MinnowBoard and Wifi updates

[Bruce Ashfield]

On 13-11-13 10:41 AM, Darren Hart wrote:
> On Wed, 2013-11-13 at 10:23 -0500, Bruce Ashfield wrote:
>> On 13-11-13 01:59 AM, Darren Hart wrote:
>>> On Tue, 2013-11-12 at 23:18 -0500, Bruce Ashfield wrote:
>>>> On 11/12/2013, 4:27 PM, Darren Hart wrote:
>>>>> On Tue, 2013-11-12 at 15:59 -0500, Bruce Ashfield wrote:
>>>>>> On 13-11-11 06:25 PM, Darren Hart wrote:
>>>>>>> The following changes since commit f1c9080cd27f99700fa59b5375d1ddd0afe625ad:
>>>>>>>
>>>>>>>       meta/common-pc: add missing dependencies for BRCMSMAC (2013-11-03 23:01:35 -0500)
>>>>>>>
>>>>>>> are available in the git repository at:
>>>>>>>
>>>>>>>       git://git.yoctoproject.org/linux-yocto-contrib dvhart/3.10/meta
>>>>>>>       http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=dvhart/3.10/meta
>>>>>>>
>>>>>>> Darren Hart (4):
>>>>>>>       minnow: Remove eg20t
>>>>>>>       minnow-io: Add feature for MinnowBoard GPIO keys and LEDs
>>>>>>>       minnow: Remove old patches for Ethernet and GPIO
>>>>>>
>>>>>> To confirm. We still want standard/minnow to contain these changes ?
>>>>>> That's what the meta data tells me, but I wanted to be sure.
>>>>>
>>>>> No, the new BSP will use standard/base. There is no real need to have a
>>>>> standard/minnow branch as far as I can see.
>>>>
>>>> That's what I was wondering and thinking as well. When I was merging the
>>>> changes I noticed the minnow-standard.scc still had a branch statement.
>>>> Did you want to quickly roll that removal into this series while you
>>>> are updating the meta data ?
>>>
>>> I hadn't thought of this. I thought the purpose of the branch statement
>>> in the minnow BSP scc was to provide a starting point to add anything
>>> the kernel BSP or the recipe BSP added to the kernel sources -
>>> independent of whether or not the standard/branch actually existed.
>>
>> The branch will be created when the statement is processed. If anything
>> happens after the statement, the changes go on that branch.
>>
>> So by just having it there, you are creating a placeholder branch.
>>
>> It is trivial to create the branch later if there really is custom
>> content. So if you don't want to have it sitting there, then drop
>> the branch statement for now.
>>
>> There are definitely two schools of thought on this. Those that want
>> to just build from a common branch, and those that follow the
>> 'branches are simple and cheap' and they document what boards are
>> supported .. so use them and be happy.
>>
>> The tools support both, and we can do either. In different contexts
>> I'm opinionated one way or the other :)
>
>
> In that case, having fewer IA branches is more in keeping with the
> Intel's goals for BSP management. Single-Image, single sources, no
> vendor trees. I'll respin the series, dropping the branch in the minnow
> scc files.
>
> Some documentation needs to be updated... I'll have to own that.

And should I expect a v3 with the removal of the branch ?

Bruce

>
> --
> Darren
>
>>>
>>> I don't know what best practice is here - maybe we're establishing it
>>> now. What would you suggest?
>>
>> see above.
>>
>>>
>>>>
>>>>>
>>>>> I suppose ultimately the BSP branches from standard/base and then
>>>>> applies the minnow-io feature, but that is meant to be optional at the
>>>>> BSP (recipe-space) level.
>>>>>
>>>>> I'd like *ALL* Intel BSPs to ultimately build from standard/base.
>>>>>
>>>>> So - is there any reason to have standard/minnow lying around? I've
>>>>> removed it from my test builds.
>>>>
>>>> How are you working with the minnow-io feature ? I can answer the minnow-io
>>>> question and the fate of the branch with that answer :)
>>>
>>> I plan to have the minnow layer linux-yocto bbappend add minnow-io as a
>>> KERNEL_FEATURE. This makes it easy to leave it out (which is good as it
>>> is an abomination of boardfiles).
>>
>> Aha.
>>
>> The only issue you could run into here is that the patches will be
>> applied at build time. Which means that if I merge anything to the
>> base that conflicts, you need to refresh the patches. I hate build time
>> patch breakage .. since it is the last thing you want to see when just
>> trying to build a board.
>>
>> The only alternative to avoid alternative is to get them on a branch
>> (*cough* standard/minnow-<foo>) or in that staging branch you had
>> before, and go with the git merge (but the merge can fail, but at
>> least the patches can be rebased on the branch to deal with the
>> conflict and everyone stays in sync).
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>>
>>>> I ask, because I didn't see it in the series being included or merged
>>>> (or did I miss it?) from the BSP .scc files themselves.
>>>
>>> Right, I didn't even think of it. Open to suggestions.
>>>
>>> My current thinking is that we should probably remove it from every BSP
>>> that starts using standard/base as its KBRANCH - this removes complexity
>>> from the BSP scc, and that is almost always a good thing in this space.
>>>
>>
>