On 09/02/2018, 9.51, "Development on behalf of Lars Knoll" 
<development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of 
lars.kn...@qt.io> wrote:

       
    > On 9 Feb 2018, at 08:13, Thiago Macieira <thiago.macie...@intel.com> 
wrote:
    > 
    > On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote:
    >> IMHO, you need to rethink your whole CI approach. This is increasingly 
being
    >> the one bottleneck slowing down Qt development and releases. It might 
make
    >> more sense to try a different approach, such as allowing all commits
    >> through initially, then making CI runs at regular intervals, and 
triggering
    >> reverts if things broke.
    > 
    > Which will happen ALL the time. We'll never get back down: when we 
released Qt 
    > 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only 
happened 
    > for QWS). For the other platforms, the normal number was a hundred tests 
    > failing. Then we spent weeks trying to get the number down.
    > 
    > Sorry, I don't want to go back to that.
    
    I 100% agree with Thiago. We’ve been there, tried that and it didn’t work. 

Tuukka: Same here. We should continue to add automation and test coverage in 
different platforms, rather than reduce it. We need to get the infrastructure 
stability into shape and continue improving the test asset continuously.

    > 
    >> Qt is being developed very much as a corporate project. (I write "as" 
rather
    >> than "like" because that's what Qt is, despite Open Governance.) It would
    >> help to look at how community Free Software projects do things. They tend
    >> to be more efficient. And some company-developed Free Software projects
    >> have already adopted such processes.
    > 
    > It would not do us well to look at poorer practices than what we have. 
Just 
    > because everyone else is where we were 10 years ago is no reason for us 
to go 
    > back to it. Show us a *better* model, one that still prevents failures 
from 
    > being added, and we'll consider it. 
    > 
    > The only one I know that fits the bill is the OpenStack model. Like Qt's, 
    > staged commits get tested *before* they are added to the mainline. The 
    > difference is that they have a massive datacenter, so they can run more 
    > quickly. They have even enough spare capacity to bisect the commits being 
    > added and figure out which one introduced the failure. We can't do that.
    
    This is what we’re trying to fix by improving our CI capacity. I believe 
there are more things we need to do, but speeding up our turnaround time in CI 
is one of the most important things here. The rest is stability of the system 
and flaky tests. Both are things we need to work on.

Tuukka: Exactly. This is the first step, and it should help already 
significantly. In addition we need to solve the issues with multiple branches 
open, as discussed earlier. This probably needs some changes to the current 
practices, so that we can get the needed fixes faster to all branches. Capacity 
and stability need to be fixed first, but most likely are not enough. 


    > 
    >> Just my 2 cents as a (mostly) packager and application developer.
    > 
    > And my 2 cents as a core developer, maintainer, open source & community 
    > expert, and someone who has followed the subject for the past 12 years.
    
    Cheers,
    Lars
    
    _______________________________________________
    Development mailing list
    Development@qt-project.org
    http://lists.qt-project.org/mailman/listinfo/development
    

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to