[oe] OE Staging ABI Change Warning

[Richard Purdie]

On Mon, 2008-03-03 at 13:46 +0100, Koen Kooi wrote:
> Holger Freyther schreef:
> The previous consensus to that proposal was "we should be able to do
> cleanups in-place". I still think we should start such a branch where we
> can do the clean up while retaining the history. Those cleanups would
> consist of:
> 
> a) basic janitorial stuff:
> 
> * running the recipe through oe-stylize.py and fix accordingly
> * document patches (origin, upstream status, etc)
> * restucrure FILESDIR to avoid duplicate files (e.g. files/foo.patch
> bar-1.0/foo.patch, etc)
> 
> b) updating to OE standards
> 
> * Replace custom methods with standards ones where appropriate (e.g.
> do_stage() -> autotools_stage_all
> * document remaining custom methods (e.g. do_configure_append sed magic)
> * sanitize PACKAGES and FILES
> * sanitize overrides (e.g. fix all the CONFFILES_nylon stuff)
> 
> c) unit testing
> 
> * compile for different archs
> * run through insane
> 
> Regardless if we create a branch for that or not, we should declare a
> freeze for e.g. 3 months where only bugfixes and cleanups are allowed to
> be checked in.

I like the idea of a cleanup process, I don't like the ideas of
branching or freezing since I think we don't have the manpower for it.

With this in mind I'd propose we just mark clean/active recipes somehow,
probably by setting a variable in them. We can then work out which
recipes have been looked at and which haven't which is the current
problem at the moment. Including a date in this variable might be good. 

One thing I did with Poky's autobuilder to improve QA was activating
world builds. We now have a list of known broken recipes in the
distro.conf file which excludes the problems from the world builds (with
reasons why). When people check anything further into Poky, we get to
know if it breaks anything "known to build" very quickly. Obviously I
aim to have a list of zero excludes eventually.

So, I guess what I'm saying is I'd like to see regular world builds of
OE with say Angstrom as a distro since it has the widest coverage and a
list of known failures created. Any new failures can then be identified
and both these and existing failures can be addressed over time.

I know angstrom is doing some kind of autobuilds but I don't know to
what extent or what policies govern what is built. I also know the nslu2
people maintain lists of packages to build and not to build. If we could
somehow pool this information that would be ideal.

I'm also giving serious consideration to expanding the suite of qemu
machines like qemuarm/qemux86 so even people without access to hardware
can run tests on the hardware QEMU supports. Poky uses the qemu machines
for the world builds on the basis that they make a good test target in
that if they build, most other things probably will too. The main thing
preventing me from doing this is time at the moment.

Cheers,

Richard