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
>>> 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,
>> 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.
> Development mailing list
Development mailing list