> On 8 Feb 2018, at 08:35, Thiago Macieira <thiago.macie...@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 

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.


Development mailing list

Reply via email to