[oe] bitbake does not fail when QA issues encountered

[Stefan Schmidt]

Hello.

On Fri, 2011-02-04 at 09:37, Frans Meulenbroeks wrote:
> 2011/2/4 Stefan Schmidt <stefan at datenfreihafen.org>:
> >
> > On Fri, 2011-02-04 at 08:54, Frans Meulenbroeks wrote:
> >> 2011/2/4 Tom Rini <tom_rini at mentor.com>:
> >> > On 02/03/2011 03:20 PM, Denys Dmytriyenko wrote:
> >> >>
> >> >> So, do you ack the patch, should I push it in? It will break the build for
> >> >> anyone still using libtool-2.2, specifically in gettext package...
> >> >
> >> > So, that would break angstrom-2008.1 so I don't think that's a great idea
> >> > until we fix it..
> >>
> >> Then again, if we push it there will be some incentive to fix it.
> >
> > So you are going to care care about the not yet ready for libtool 2.4 fallout?
> > Get warm with openjdk-6 then as it still needs libtool 2.2. :)
> >
> > More serious, I think this should at least wait until after the upcoming 2011-03
> > release. We need to find a balance between waiting forever and not breaking
> > existing stuff.
> >
> Ehm, so if there is an RPATH or GNU_HASH QA error the code is *not* broken?
> In that case it should not be a QA error but a QA warning.
> But if it is an error then the existing stuff is already broken.

My comment did target the force of libtool 2.4 to everyone. Reading it again I
think I made this clear. I don't think that RPATH or GNU_HASH errors are
invaldid or should be ignored I'm just pointing out that foricing an update to
libtool 2.4 will break other things. (Which should obviously get fixed as well).

Taking my OE hat off and my BugLabs build guy hat on I can tell what I would do
with such a change going in now. I would skip the next release I wanted to base
a product on and just keep a private branch from a known good rev and release
from there maybe pulling in fixes over time. This is the exact opposite we
should aim for when doing releases. Instead we should get the metadata in good
shape for as much customer as possible, release, allow pooling of resources on
such a release for potential maintenance and get problematic stuff in _early
after the release_. Call it merge window or whatever.

I'm happy to work on getting openjdk work together with libtool 2.4, but not
before a upcoming release. Thats more like throwing stave in between peoples
legs. (Not sure if such a german saying makes much sense translated. :))

> Ignoring the error then is more like ostrich behaviour.

And waht is ignoring my statement about balace such things and wait until after
the release? :)

regards
Stefan Schmidt