[PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[Ross Burton]

It turns out that changing WARN_QA and ERROR_QA results in do_configure's QA
postfunc re-executing, so changing a QA test results in a complete rebuild.

This is just too much and the lesser evil of needing to do a full rebuild to
verify changed QA flags is preferable to an enforced full rebuild.

This reverts commit daecfc3438122b5d146a59a5053e57006d55ccc4.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/conf/bitbake.conf |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 907ed1e..b5b54b7 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -774,7 +774,7 @@ BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
     USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
     PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
     CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX \
-    WORKDIR STAMPCLEAN PKGDATA_DIR"
+    WARN_QA ERROR_QA WORKDIR STAMPCLEAN PKGDATA_DIR"
 BB_HASHCONFIG_WHITELIST ?= "${BB_HASHBASE_WHITELIST} DATE TIME SSH_AGENT_PID \
     SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS \
     PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED"
-- 
1.7.10.4

Re: [PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[Paul Eggleton]

On Wednesday 04 February 2015 21:33:36 Ross Burton wrote:
> It turns out that changing WARN_QA and ERROR_QA results in do_configure's QA
> postfunc re-executing, so changing a QA test results in a complete rebuild.

Hmm, shouldn't we be fixing this? (e.g. with vardepsexclude).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[Richard Purdie]

On Fri, 2015-02-06 at 10:41 +0000, Paul Eggleton wrote:
> On Wednesday 04 February 2015 21:33:36 Ross Burton wrote:
> > It turns out that changing WARN_QA and ERROR_QA results in do_configure's QA
> > postfunc re-executing, so changing a QA test results in a complete rebuild.
> 
> Hmm, shouldn't we be fixing this? (e.g. with vardepsexclude).

Well, either the tests should rerun or they shouldn't. I'm not sure "the
configure tests don't" would be an improvement?

Cheers,

Richard

Re: [PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[Otavio Salvador]

On Fri, Feb 6, 2015 at 9:42 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2015-02-06 at 10:41 +0000, Paul Eggleton wrote:
>> On Wednesday 04 February 2015 21:33:36 Ross Burton wrote:
>> > It turns out that changing WARN_QA and ERROR_QA results in do_configure's QA
>> > postfunc re-executing, so changing a QA test results in a complete rebuild.
>>
>> Hmm, shouldn't we be fixing this? (e.g. with vardepsexclude).
>
> Well, either the tests should rerun or they shouldn't. I'm not sure "the
> configure tests don't" would be an improvement?

I think they should re-run. Otherwise we can end having errors and QA
issues unnoticed until a full rebuild.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

On 6 February 2015 at 14:10, Otavio Salvador <otavio@ossystems.com.br>
wrote:

> I think they should re-run. Otherwise we can end having errors and QA
> issues unnoticed until a full rebuild.
>

That was the state of things until my original patch last week.  The patch
had the side-effect that changing QA tasks causing *everything* to
rebuild.  I'm really not sure that's a good solution.

Ross

[-- Attachment #2: Type: text/html, Size: 824 bytes --]

Re: [PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[Otavio Salvador]

On Fri, Feb 6, 2015 at 12:18 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> On 6 February 2015 at 14:10, Otavio Salvador <otavio@ossystems.com.br>
> wrote:
>>
>> I think they should re-run. Otherwise we can end having errors and QA
>> issues unnoticed until a full rebuild.
>
>
> That was the state of things until my original patch last week.  The patch
> had the side-effect that changing QA tasks causing *everything* to rebuild.
> I'm really not sure that's a good solution.

If someone adds a QA tasks it is because it matters. In this case we
ought to have it in an immediate effect so it does makes sense to
rerun everything.

I know it is bad from build time point of view but predictability and
correctness is more important from my point of view.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

On Fri, Feb 06, 2015 at 12:21:23PM -0200, Otavio Salvador wrote:
> On Fri, Feb 6, 2015 at 12:18 PM, Burton, Ross <ross.burton@intel.com> wrote:
> >
> > On 6 February 2015 at 14:10, Otavio Salvador <otavio@ossystems.com.br>
> > wrote:
> >>
> >> I think they should re-run. Otherwise we can end having errors and QA
> >> issues unnoticed until a full rebuild.
> >
> >
> > That was the state of things until my original patch last week.  The patch
> > had the side-effect that changing QA tasks causing *everything* to rebuild.
> > I'm really not sure that's a good solution.
> 
> If someone adds a QA tasks it is because it matters. In this case we
> ought to have it in an immediate effect so it does makes sense to
> rerun everything.
> 
> I know it is bad from build time point of view but predictability and
> correctness is more important from my point of view.

Agreed, especially when someone decides to make something fatal it
should highlight all failing recipes before it's enabled in "official"
build instead of sneaking the failures one-by-one as sstate is being
invalidated by other changes.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[Richard Purdie]

On Fri, 2015-02-06 at 16:02 +0100, Martin Jansa wrote:
> On Fri, Feb 06, 2015 at 12:21:23PM -0200, Otavio Salvador wrote:
> > On Fri, Feb 6, 2015 at 12:18 PM, Burton, Ross <ross.burton@intel.com> wrote:
> > >
> > > On 6 February 2015 at 14:10, Otavio Salvador <otavio@ossystems.com.br>
> > > wrote:
> > >>
> > >> I think they should re-run. Otherwise we can end having errors and QA
> > >> issues unnoticed until a full rebuild.
> > >
> > >
> > > That was the state of things until my original patch last week.  The patch
> > > had the side-effect that changing QA tasks causing *everything* to rebuild.
> > > I'm really not sure that's a good solution.
> > 
> > If someone adds a QA tasks it is because it matters. In this case we
> > ought to have it in an immediate effect so it does makes sense to
> > rerun everything.
> > 
> > I know it is bad from build time point of view but predictability and
> > correctness is more important from my point of view.
> 
> Agreed, especially when someone decides to make something fatal it
> should highlight all failing recipes before it's enabled in "official"
> build instead of sneaking the failures one-by-one as sstate is being
> invalidated by other changes.

Thinking about this from the other angle. Should someone having a
different set of WARN/ERROR local settings mean they don't reuse sstate?

Cheers,

Richard

Re: [PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[Otavio Salvador]

On Fri, Feb 6, 2015 at 1:13 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2015-02-06 at 16:02 +0100, Martin Jansa wrote:
>> On Fri, Feb 06, 2015 at 12:21:23PM -0200, Otavio Salvador wrote:
>> > On Fri, Feb 6, 2015 at 12:18 PM, Burton, Ross <ross.burton@intel.com> wrote:
>> > >
>> > > On 6 February 2015 at 14:10, Otavio Salvador <otavio@ossystems.com.br>
>> > > wrote:
>> > >>
>> > >> I think they should re-run. Otherwise we can end having errors and QA
>> > >> issues unnoticed until a full rebuild.
>> > >
>> > >
>> > > That was the state of things until my original patch last week.  The patch
>> > > had the side-effect that changing QA tasks causing *everything* to rebuild.
>> > > I'm really not sure that's a good solution.
>> >
>> > If someone adds a QA tasks it is because it matters. In this case we
>> > ought to have it in an immediate effect so it does makes sense to
>> > rerun everything.
>> >
>> > I know it is bad from build time point of view but predictability and
>> > correctness is more important from my point of view.
>>
>> Agreed, especially when someone decides to make something fatal it
>> should highlight all failing recipes before it's enabled in "official"
>> build instead of sneaking the failures one-by-one as sstate is being
>> invalidated by other changes.
>
> Thinking about this from the other angle. Should someone having a
> different set of WARN/ERROR local settings mean they don't reuse sstate?

It should be checked against the different setting. If the price for
it is sstate invalidness, so be it.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH] Revert "bitbake.conf: don't remove WARN_QA and ERROR_QA from hashes"

[Paul Eggleton]

On Friday 06 February 2015 13:53:42 Otavio Salvador wrote:
> On Fri, Feb 6, 2015 at 1:13 PM, Richard Purdie
> 
> <richard.purdie@linuxfoundation.org> wrote:
> > On Fri, 2015-02-06 at 16:02 +0100, Martin Jansa wrote:
> >> On Fri, Feb 06, 2015 at 12:21:23PM -0200, Otavio Salvador wrote:
> >> > On Fri, Feb 6, 2015 at 12:18 PM, Burton, Ross <ross.burton@intel.com> 
wrote:
> >> > > On 6 February 2015 at 14:10, Otavio Salvador
> >> > > <otavio@ossystems.com.br>
> >> > > 
> >> > > wrote:
> >> > >> I think they should re-run. Otherwise we can end having errors and
> >> > >> QA
> >> > >> issues unnoticed until a full rebuild.
> >> > > 
> >> > > That was the state of things until my original patch last week.  The
> >> > > patch
> >> > > had the side-effect that changing QA tasks causing *everything* to
> >> > > rebuild.
> >> > > I'm really not sure that's a good solution.
> >> > 
> >> > If someone adds a QA tasks it is because it matters. In this case we
> >> > ought to have it in an immediate effect so it does makes sense to
> >> > rerun everything.
> >> > 
> >> > I know it is bad from build time point of view but predictability and
> >> > correctness is more important from my point of view.
> >> 
> >> Agreed, especially when someone decides to make something fatal it
> >> should highlight all failing recipes before it's enabled in "official"
> >> build instead of sneaking the failures one-by-one as sstate is being
> >> invalidated by other changes.
> > 
> > Thinking about this from the other angle. Should someone having a
> > different set of WARN/ERROR local settings mean they don't reuse sstate?
> 
> It should be checked against the different setting. If the price for
> it is sstate invalidness, so be it.

I honestly don't think this is right. The value of this variable does not 
belong in the signature - it does not affect the output of do_configure.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre