08.02.2018, 11:17, "Lars Knoll" <lars.kn...@qt.io>:
>>  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 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.

Have you considered assigning priorities to CI jobs?

>
> 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
>
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin

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

Reply via email to