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

Lars Knoll lars.knoll at qt.io
Thu Feb 8 09:17:35 CET 2018


> On 8 Feb 2018, at 08:35, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On Wednesday, 7 February 2018 19:32:25 PST Kevin Kofler wrote:
>> We are now in early February. By your schedule, 5.11 will be out on the last
>> day of May. That's a whopping 4 months without a Qt release from the
>> current (non-LTS) branch! In that time, at least 2 batches of Chromium
>> security updates will happen. And that does not even account for the
>> inevitable slips that consistently happen.
> 
> I want to point out that we appeared to have fixed our release problems. The 
> last time we had released a .2, aside from the LTS 5.6.2, was 5.4.2.

Yes, I think we have fixed most of the problems related to getting releases out. What we haven’t yet fixed good enough is how to work with 5 open branches at the same time. The cost of handling those is largely invisible to those not doing the work, but it’s there. The merges from one branch to the next plus updates to qt5.git are the main problem here. Those do cost a lot of time and effort that go away from bug fixing and testing.

> 
> But we HAD fixed the problem. 5.9.2 was released before 5.10.0. In fact, even 
> 5.9.3 was released before 5.10.0. This means we managed TWO releases between 
> 5.9.1 and 5.10.0. Taking this to the case now, it would allow us to release 
> 5.9.5 and 5.10.2 before 5.11.0 if we wanted to.

Most of the releases were done form 5.9, where we do not have a problem that we need to merge changes from another branch. But getting 5.10 out was again pretty painful due to the merges from 5.9. We often had very long times between successful qt5.git updates. Having one additional branch with both 5.10 and 5.11 and dev where we need to cascade merges will make that problem quite a bit bigger. 

So we’re still not in the world I’d like to have where we can handle multiple branches in a good way. This is something we need to try to solve and find ways to handle better. 

One thing we’re doing currently is adding more capacity to CI. This has been a bottleneck that was slowing down merges and qt5.git updates. Better capacity should be in place in early spring. 

The other thing I believe we need to do is to find ways to automate merges between branches and do those one a more continuous basis. Currently we often ended up waiting many days until a fix had been merged into all relevant branches, leading to delays in different places. Ideally those merges should happen daily, not once every two weeks.

If required, we could probably still do a 5.10.2, but if we do it, I’d like to limit that one to security issues, and avoid the long merge chain from 5.10 to dev until we have figured out how to handle that better.

Cheers,
Lars



More information about the Development mailing list