[Development] The qtbase CI should run the qtdeclarative tests

Rohan McGovern rohan.mcgovern at nokia.com
Mon Mar 19 10:29:01 CET 2012


Knoll Lars (Nokia-MP/Oslo) said:
> On 3/19/12 2:11 AM, "ext Rohan McGovern" <rohan.mcgovern at nokia.com> wrote:
> 
> >marius.storm-olsen at nokia.com said:
> >> While it's not normal to do this type of dependency "lock" for upwards
> >>dependencies, i think in this case we should indeed do the extra
> >>checking. Not just because QtDeclarative is such an important tech for
> >>Qt5, but also because it's a very good test case for QtBase.
> >> 
> >
> >What would be the proposed workflow to resolve this situation?
> >
> >  - I have a change in qtbase which I can't push because it breaks a
> >    qtdeclarative test.
> >
> >  - I have a fix to the test in qtdeclarative but I can't push it
> >    because it doesn't pass without my qtbase change.
> >
> >One solution I can think of is to introduce a %reverse_dependencies
> >in sync.profile, used for CI and nothing else, which can control the
> >SHA1 of qtdeclarative used while testing qtbase.
> 
> The easiest way is probably to do it in 3 stages:
> * Pin the SHA1 of qtbase in declarative
> * Submit the qtbase change
> * Unpin the sha1 and submit the declarative fix.

I don't understand this suggestion.
If qtdeclarative's sync.profile has pinned to a particular qtbase SHA1,
that shouldn't affect the "with declarative" qtbase CI configuration,
right?  So how does it resolve the deadlock?

Or do you think declarative's sync.profile _should_ affect the "with
declarative" qtbase CI config?  That means pinning a qtbase SHA1 in
qtdeclarative effectively disables this config, since you'll be testing
qtdeclarative's requested qtbase SHA1 which does not include the incoming
qtbase changes.



More information about the Development mailing list