Re: OMAP34xx

Russell King - ARM Linux
2012-02-05T00:09:39Z

On Sat, Feb 04, 2012 at 03:05:07PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [120204 12:03]:
> > I'm seriously considering requesting that all OMAP changes for the merge
> > window come through me rather than arm-soc, so that I can boot and build
> > test them before the merge window opens, and we can cut down on this
> > repetitive cycle of build (and boot) breakage at every merge window.
>
> I agree it would be nice to see these issues earlier. I build and boot
> test every patch I merge, but mostly with omap2plus_defconfig as that
> does the job for all the boards I have with a single zImage.
>
> Looks like the issues you're seeing are related to .config settings.
>
> How about let's plan on testing your .configs with for-next before the
> next merge window?

I was thinking about something more than just a build-test, because
that's just a part of the problem.

Let me make it clear what my motivation here is (before someone starts
making any accusations).

There is a view widely held that the mainline OMAP kernels are in a
pretty poor shape when it comes to people being buildable (I've been
told so.) That reflects my experience each cycle when I try to test
a mainline OMAP kernel - and I invariably encounter build or boot
problems of various degrees.

What I would _prefer_ to see is that your tree gets build _and_ boot
tested by people in the OMAP community with a range of configurations,
and any build or boot problems get reported back in a timely manner
so that those problems can be solved before the tree goes to arm-soc.

Obviously, some of that does happen, but it's clearly not enough as
we keep going around this loop at every merge window where there's
breakage each time, there isn't enough of it. So, we need a different
solution to this.

So, I was thinking about pulling your tree, building and booting
it _and_ requiring it to pass before it goes to mainline. Yes, that's
pretty drastic, but I think it's about the only way to ensure that
the amount of regressions are reduced down to an acceptable level.

Let's be clear - I'm not talking about the pulls that you'd send to
Arnd and Olof for fixes during or after the merge window. I'm talking
about the merge window stuff only - because that seems to be where most
of the breakage happens.

I've been wondering whether I could set something up which did this all
automatically - maybe running a build overnight and then automatically
boot testing it and logging the results - including running some
userspace testing. One of the issues I'd face is that my current build
machine is the laptop, which isn't aways available to run the builds
each day.

But... things are complicated by the OMAP boards having USB to serial
devices on them rather than standard RS232, which rather limits what I
can do to automate testing with them, especially as others require a
USB socket as a source of power to run themselves.