[oe] bitbake does not fail when QA issues encountered

[Frans Meulenbroeks]

2011/2/4 Stefan Schmidt <stefan at datenfreihafen.org>:
> 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? :)
>
Hi Stefan,

Actually I did not react on the libtool forcing upon everyone, but on
the QA errors (where this thread was about).
That was also the cause of the ostrich remark (which was definitely
not aimed at you in person, but more a general comment, triggered by
the fact that I have some experience with projects being outsourced to
an unnamed country where a bug report also could be "repaired" by
removing the message or the the symptom instead of tackling the root
cause).

What I see is a lack of interest in fixing the existing QA errors.
I've sent out a few error reports to the list a while ago, (on recipes
that I feel not comfortable with), but unfortunately that did not
result in any action :-(

Best regards, Frans.