Boot time errors/warnings on snowball

Lee Jones lee.jones at linaro.org
Thu Dec 5 03:04:06 EST 2013


> > I know that you've had a bee in your bonnet about the rate of which I
> > sent patches for a while, but this instance has nothing to do with
> > rushing. This is merely an ordering issue and the speed in which
> > varying subsystems are merged into -next.
> > 
> > This is what -next is for though right? To identify these kinds of
> > decencies before they're merged into Mainline. So let's do something
> > about it now. I'm not sure what though, as I know that Mark isn't fond
> > of rebasing his tree.
> 
> You can't solve dependencies by "tree X needs to merge before tree Y
> otherwise Z breaks", period.
> 
> It gives the _illusion_ that it solves it, but it doesn't.  Just try
> doing a git bisect and hitting commits in tree Y without tree X being
> merged.  By doing it this way, you're basically telling people that
> you can't bisect a merge window.  The merge window is _precisely_ the
> period where we need bisectability to find bugs.

Right, Olof was already kind enough to point this out:

 "It can be done. It's unfortunate to lose bisectability though (since
  when you bisect you can end up in a state where the ASoC patches are
  enabled but not the ux500 counterparts. Setting up a shared branch
  is indeed the best (only) way to solve that. Next time around we
  should do so."
 
Which reminded me of "how git works"; non-linear history, yada yada.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog



More information about the linux-arm-kernel mailing list