Knoll Lars (Nokia-MP/Oslo) said: > On 3/19/12 2:11 AM, "ext Rohan McGovern" <[email protected]> wrote: > > >[email protected] 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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
