09.02.2018, 10:03, "Kevin Kofler" <kevin.kof...@chello.at>:
> IMHO, you need to rethink your whole CI approach. This is increasingly being
> the one bottleneck slowing down Qt development and releases. It might make
> more sense to try a different approach, such as allowing all commits through
> initially, then making CI runs at regular intervals, and triggering reverts
> if things broke.

>From what I see, CI is not the bottleneck, or at least not the only one. From 
>reading
this list I got impression that situation is quite different. We may have 
stable branch
with a good number of fresh unreleased commits, but release team rejects 
possibility
of making point release, because release process requires a lot of time and they
need that time for doing something more important [1].

One notable example was with Qt 5.9.3, when Linux binaries were accidentally 
built
using too fresh GCC version. It was proposed that we rebuild 5.9.3 tag as is 
using
different toolchain, so no new merges were needed and CI delays could have only
minimal influence on the release timing. Anyway this was rejected, apparently
because verifying binaries before releasing them requires too much effort [2].


[1] Please don't take this as I'm trying to put a blame on anyone, I'm 
willingly believe
release team is doing their best
[2] https://www.mail-archive.com/development@qt-project.org/msg30384.html

-- 
Regards,
Konstantin

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

Reply via email to