[Development] Grooming the merges?

[Mutz, Marc]

On 2019-07-17 08:05, Mutz, Marc via Development wrote:
> The qt5.git integration[1] hasn't happened for a month or so (ok two
> weeks)

It still hasn't. QtBase devs need an integration a week, not one per 
month, to work efficiently.

The current state is not acceptable. The integration of Jun 18th took 
three weeks, the one on May 9th, too, and the one in Mar 5th almost 
four, so roughly every 2nd month this year, we've been without 
integration for weeks on end. Absent any other, less aggressive, 
options, I'm going to propose the following as a QUIP:

- commits that break a qt5 integration run are immediately reverted, no 
+2 from someone else than the integrator needed, and qt 5 integration is 
attempted immediately anew after the reverts integrated in their module.

- any commits that depend on the to-be-reverted commit (semantically or 
syntactically) are reverted (in reverse order), too.

This should be rare if we succeed with the plan further below, but, 
IIRC, this was an enabler to get one of the June integrations going: 
temporarily revert the deprecation of QAtomic::load().

This should have happened also for whatever QML header reorg was causing 
compile failures in qtxmlpattern, qtlocation, and who knows where.



Going forward, reviewers should make sure that incompatible changes 
(incl. to private headers, and deprecations) are done in smaller steps:
   1. (base module) prepare for the change (add the replacement function 
as an overload, add a macro that implementations can check and that 
defaults to 'old'.
   <qt5 integration>
   2. (all dependent modules) adapt to the change, using macros, if 
needed
   3. (base module) introduce or finalize the change (add the deprecation 
macros, remove the old API)
   <qt5 integration>
   4. (all dependent modules) remove the work-arounds

In general, 1-4 should be in the hand of one team/developer, and please 
use topic branches to track changes across modules. It's ok to not catch 
all instances in the end, that's what the CI is for. But it should not 
happen that complete modules are forgotten.

As an extremely long-running example, consider Q_FOREACH. I've been 
carrying the deprecation in my tree for four years now. I've come to 
realize that I will never be able to port them all, so I added 
QT_NO_FOREACH and set it on module after module to prevent new uses from 
creeping in. We're now in a position where there's only handful of 
modules left that don't have it, and we could make QT_NO_FOREACH the 
default, with modules lagging behind having to explicitly disable it.

We've come to that point already with QT_NO_LINKED_LIST and 
QT_NO_JAVA_STYLE_ITERATORS. We can now globally enable them. The last 
uses in QtBase (tests) already undef them.

For an example at a somewhat lower scale, please look at the ongoing 
work to decouple QRecursiveMutex from QMutex: 
https://codereview.qt-project.org/q/topic:qrecursivemutex

Flame away.

Thanks,
Marc