From: Knoll Lars >On 13/05/14 11:49, "Bubke Marco" <marco.bu...@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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
