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

[Darren Hart]

On 03/14/2012 01:25 PM, Bruce Ashfield wrote:
> On 12-03-14 10:45 AM, Darren Hart wrote:
>> 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
> 
> That can be done .. and I've done it in the past, dynamic branches
> are supported within the tools. But there are always issues:
> 
>    - anything dynamic is never as smart as someone specifying a feature
>      description and deciding whether or not they want a branch. I've
>      nearly always regretted dynamically creating branches in the past.
> 
>    - It's not just machine descriptions that trigger merges, any feature
>      can have one if it has a topic branch that is being maintained in
>      that manner. So I tread carefully here to not introduce special
>      cases. We are talking about a known optional, board specific merge.
>      A human can make that call pretty easily and specify that they
>      want a branch.
> 
>    - Some people just like to build the branch that they want to build.
>      Since, for example, they might be pushing changes onto a non
>      machine specific branch and expecting it to build .. and sometimes
>      that branch isn't even the parent branch (i.e. some temp build). It
>      also means that working in the build tree patches don't have a 1:1
>      home in a source repository. But there are other things that make
>      this a non-ideal workflow, so I don't really mind making it harder :)
> 
>      That was the whole intent of KBRANCH. You specify explicitly what
>      you want to build, and the system lets you build that branch. This
>      means that you'll build the same content .. but maybe not that
>      branch.
> 
>    - Tree generation would have to dynamically create them, and then
>      remove the non-static branches when it completed. Completely doable,
>      but with a complexity cost. Complete tree generation and per-machine
>      building would now differ (although minor).
> 
>> 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.
> 
> There are far worse examples of non-obvious branches out there, but
> I don't disagree with the principle.
> 
>>
>> 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.
> 
> I don't really have big problem with people working on machine branches :)
> It's just a topic branch that holds work, it's like anything you do in
> a git repo .. do it on your own branch .. and then merge it back.
> 
> Anyway, I'm making changes to quite a few things right now in the tools,
> and we don't want to do this for 1.2, so let me think about this for a
> day and see if any other use cases break.
> 

Yes, let's revisit after 1.2 is out. Not need to muddy the waters with
it now.

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