On 09/02/2018, 9.51, "Development on behalf of Lars Knoll"
<development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of
> On 9 Feb 2018, at 08:13, Thiago Macieira <thiago.macie...@intel.com>
> On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote:
>> IMHO, you need to rethink your whole CI approach. This is increasingly
>> the one bottleneck slowing down Qt development and releases. It might
>> more sense to try a different approach, such as allowing all commits
>> through initially, then making CI runs at regular intervals, and
>> reverts if things broke.
> Which will happen ALL the time. We'll never get back down: when we
> 4.2, 4.3 and 4.4, we were happy if only 10 tests failed (that only
> 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"
>> 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.
> because everyone else is where we were 10 years ago is no reason for us
> back to it. Show us a *better* model, one that still prevents failures
> 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.
Development mailing list
Development mailing list