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

[Tom Zanussi]

On Wed, 2012-03-14 at 07:45 -0700, 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
> 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.
> 

In principle, I agree.  The main thing I don't like about it is the
potential there is for ping-ponging between having to add a branch
because we have a single BSP-specific patch and then having to remove
that branch again when it goes upstream or is no longer needed.

Users can use standard git queries to find out whether a machine branch
currently has anything that differs from its parent - I'm not sure
counting on the existence of a branch as a quick indicator that it
deviates from mainline is really all that useful for users, but maybe it
is.

In any case, it's a minor point and in the end if it makes things easier
for users, that trumps everything else...

Tom

> --
> 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.
> > 
> 
>