[linux-yocto] 3.10, standard/base at 3.10.17, but reverts back to 3.10.10...

[Darren Hart]

On Thu, 2013-11-07 at 11:54 -0500, Bruce Ashfield wrote:
> On 13-11-07 11:28 AM, Darren Hart wrote:

> > But, other than a bunch of hashes and control characters, very little is
> > written to do_patch around the the code that changes branches.
> 
> I've removed that for the verbose logging in the latest set of updates,
> or to be precise, a V=1 type logging that drops the spinner and shows
> you everything that happens in behind. With that, you'll see the
> existing logs that say branch <foo> (reuse), when reusing a branch.


Are these pending updates or something I already have access to?


> > So, there appear to be two uses of the same command: [branch]
> >
> >
> > 1) Create a branch from the current HEAD on which to apply additional
> >     features (merges,patches,etc).
> >
> > 2) Checkout an existing branch, and then do the patches/merges
> 
> I wouldn't call those different uses, it is always:
> 
>    - create branch from current position, re-use if there
>    - do more work.
> 
> Trust me on this, we cannot error if the branch already exists. Each and
> every time you build what is described in the meta data is validated
> against the tree, so it absolutely expects and deals with being run many
> times on the same tree.

I think I get that part, and I'm not saying we have to call this an
error. What I'm trying to address is how to close the gap in intention
versus execution.

We've actually discussed the impotency of the recipe-space KBRANCH
before, and it's still a problem we need to address. This may just be a
documentation issue in the end, but I think we could narrow the semantic
gap with the tooling as well.

For example:

1) What does it mean to specify KBRANCH=/standard/base ?

I think the typical BSP author's expectation would be that standard/base
would be used as the base for the kernel build. Any patches or features
would merged on top of that.

The reality is that any branch command in the linux-yocto meta-data
could render it completely ineffectual - or not, depending on whether or
not the target branch already exists or not. We can certainly improve
this.

2) What is the outside-of-bitbake equivalent of KBRANCH?

We should be adding some documentation on how to work with the kernel
tools outside of bitbake. Right now that is shrouded in tribal knowledge
which understandably widens the semantic gap.

--
Darren


> 
> Bruce
> 
> >
> > In general, the problem for me is that branch implies checkout. THe
> > instrumentation problem comes in that we are executing a generated file,
> > rather than marching through it, which make instrumenting it cumbersome.
> > Perhaps there is a good way, to put some print statements and if this
> > then bail out with a horrible message code in the generated code, but
> > the tooling is generic enough as make this difficult. I'll comment on
> > this more in your other response after I drive in...
> >
> 

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