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

[Bruce Ashfield]

On 12-03-14 4:40 PM, Darren Hart wrote:
>
>
> 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.

+1 .. and I forgot to type in my last email, that all of the points I
mention are minor, so really, with the right tweak .. I think this is
a fine idea.

Cheers,

Bruce

>