[Development] Qt branches & proposal how to continue with those

[Lars Knoll]

> On 9 Feb 2018, at 08:13, Thiago Macieira <thiago.macieira at 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. 
> 
>> 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.
> 
>> 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