[Development] Modules in qtbase (was: Re: new "debugsupport" module and API)

[Bubke Marco]

From: Knoll Lars
>On 13/05/14 11:49, "Bubke Marco" <Marco.Bubke at digia.com> wrote:
>>Actually the different the difference between qtdeclarative and qtbase is
>>already producing enough overhead. For example bisect is hard to
>>impossible which I need to do often to find out smart changes.
>
>I very much disagree. The changes and refactorings we did to declarative
>over the last year would IMO have been a lot harder to do with a
>monolithic repository.

I don't say that it is easier if you work in the modules. I do say that it is harder 
if you work outside. For example we use now in the designer Qml and the 
controls heavily and many bugs popping up. Normally I would use bisect
to find out the change but because it is so time consuming I simply ignore
them.

>Bisecting qtdeclarative works usually well on the latest qtbase, and
>bisecting qtbase can be done independent of qtdeclarative. It’s only in
>the relatively rare case that a qtbase change caused a break in
>declarative that this is an issue. I believe that’s worth the trade off.

You see from your perspective it is easier from my it is harder.

>>What about to break the 1:1 relationship between CI modules and
>>repositories. Why not have more than one CI module for qtbase?
>
>How do you imagine that should that work in practice?

If you change a file in a module you get through that CI system. You should add
other CI modules if you think your change could triggering bugs there.

E.g. you change network code. Then the network CI should run, maybe the CI for
declarative-network and web-network too. So the CI modules should be smaller
so less unaffected code would be tested.