[yocto] [PATCH 1/2] meta-crownbay: switch to linux-yocto-3.2 kernel

[Darren Hart]

On 03/13/2012 09:12 PM, Bruce Ashfield wrote:
> On 12-03-14 12:05 AM, Darren Hart wrote:
>>
>>
>> On 03/13/2012 08:08 PM, Bruce Ashfield wrote:
>>> On 12-03-13 11:03 PM, Tom Zanussi wrote:
>>>> On Tue, 2012-03-13 at 22:40 -0400, Bruce Ashfield wrote:
>>>>> On Tue, Mar 13, 2012 at 3:44 PM, Tom Zanussi<tom.zanussi at intel.com>   wrote:
>>>>>> On Tue, 2012-03-13 at 12:30 -0700, Darren Hart wrote:

...

>>>>>>> I believe crownbay no longer requires special patches right? Can we just
>>>>>>> use the standard/default/base branch here and squash the crownbay branch?
>>>>>>>
>>>>>>
>>>>>> At the moment it doesn't, and I'll probably submit a patch to do that
>>>>>> for everything that it make sense for again after things are functional
>>>>>> with the simple changes first.
>>>>>
>>>>> There's one catch with this. We currently have the graphics drivers staged as
>>>>> topic branches so they can be in tree, and be kept pristine. The BSPs merge
>>>>> the graphics topic branch they want, and we can leverage common commits
>>>>> across all the users.
>>>>>
>>>>> If you drop the BSP branch, then the graphics changes need to be universally
>>>>> safe for all similar BSPs, since that merge will now be to a shared branch.
>>>>> That's normally fine, but for the case where we have multiple emgd versions,
>>>>> it can break things.
>>>>>
>>>>> We have complete flexibility to how we stage the branches, and how we
>>>>> generate the content that is built, so this can change .. but that's
>>>>> how we currently
>>>>> have it setup. Those graphics merges are board specific changes and require
>>>>> a branch.
>>>>>
>>>>
>>>> That's fine, I'm perfectly happy to have per-BSP machine branches.
>>>> They're cheap, and I don't really see the reason to be so parsimonious
>>>> with them.  Also, they're always there, so if we do need to have a place
>>>> to put the odd machine-specific patch now and then we don't have to add
>>>> a new branch when we need to add those patches, or remove them once
>>>> they're gone.  I guess the system was kind of designed for that (machine
>>>> branches, even if empty)?
>>>
>>> Exactly. We can collapse them where it makes sense, and keep there where
>>> we need them. A machine branch is just that, a topic branch for development
>>> and implicit documentation of a supported board. If a board may be extended
>>> in the future .. a branch is nice to have.
>>>
>>> I'm in favour of keeping the count in control, but see no need to collapse
>>> them down completely. That and I spent an hour trying to figure out
>>> how to do some fancy merge logic and while it could be done, it just
>>> makes things more complex. I'd prefer branches to overly complex
>>> branch management logic.
>>>
>>
>> Agreed on the concept. What I'm not understanding is how is having to
>> get yocto/emgd-1.10 to merge with standard/base any different than
>> having to get it to merge with:
>>
>> standard/default/crownbay
>> standard/default/common-pc-64/sugarbay
>> standard/default/fri2
>>
>> etc.
>>
>> emgd isn't premerged into these machine branches if I understand the scc
>> files correctly, so how is this any different? (I'm sure it is, I trust
>> you here, I would just like to understand what I'm missing).
> 
> When a tree is built from scratch (from the meta data + patch repo), or
> when BSP validation runs across a tree. All BSPs are constructed in a
> single tree. If you have merges into common branches, the third, fourth
> or fifth one is going to eventually explode.

It seems like the obvious answer here is to always create a machine
branch during tree construction if one does not already exist. This
would address the concerns of automated bulk validation while still
keeping the branching in the git tree to a minimum. Very few users will
be manipulating the git tree in the WORKDIR, and those that do are
expected to be advanced git users that can run:

$ git cherry standard/base

So why do I care about keeping the branch count down?

o It helps make it explicit where we have deviated from mainline.
  - Clear visibility into this is one thing that users have
    complained about.
  - It maintains the 1:1 mapping between branches and actual source
    changes we've discussed.

o It encourages people creating new BSPs to use an existing branch
  if at all possible.
  - We can encourage people to do this, but unless it is clear we
    are following this advice ourselves, others will not follow.

Taking a hard line on this is also part of boiling down our language and
firming up policy and tool definition. Doing so makes things more clear,
easier to learn, understand, contribute to, as well as maintain and debug.

--
Darren


> 
> That being said, I *can* inhibit the merges during tree construction and
> only do it when individual boards are built. But in that scenario, we miss
> an opportunity for automated/bulk validation that the merges are safe
> and valid.
> 
> So your observation is correct, and it's just a use case of the descriptions
> 
> That's why I mentioned that we can collapse them, but there is an increase
> in complexity. Something to keep in our back pocket, since it's there
> to use when we need it.
> 


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel