[Development] Are SiCs through #include cleanups considered acceptable?

[Simon Hausmann]

On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote:
> On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
> > Hi,
> > 
> > I have in the past fixed #include mistakes such as #include
> > <qsharedpointer.h> for QSharedDataPointer, and even though each time the
> > issue came up that this is a SiC change (but only for users that unduly
> > rely on indirect includes), so far they were always accepted.
> > 
> > When splitting off qHash() from qhash.h into qhashfunctions.h, I have come
> > across many files that included qhash.h without using it, and likewise
> > some
> > for which qhashfunctions.h would suffice. One of them now got a -1 for
> > being SiC.
> > 
> > Can we please decide once and for all whether #include cleanups that are
> > technically SiC are ok or not, if they only affect users that rely on
> > indirect includes?
> > 
> > My vote obviously goes to allowing them.
> 
> My vote goes against such gratuitous SiC changes.
> 
> Each little SiC changes add up in frustration for the developer who upgrades
> its Qt version.
> So when it is easy to avoid, we should avoid it.

I'm with Olivier on this one. Source compatibility is a key contribution to 
the success of Qt.

For developers building their own software it may not be such a big deal, if 
they are experienced Qt developers. For somebody who just clones a random 
project off github and then tries to build it, such a "simple" source 
incompatible change becomes a deal breaker. I argue that there's a high 
probability that person is not familiar with these types of changes nor 
knowledgeable how to fix them.

I've encountered this numerous times myself for example trying to keep the 
nvidia modules on my Laptop compiling with a changing kernel API. Often the 
fixes are _absolutely_ trivial one liners about missing includes. But I more 
often can't be bothered to dive into the source code to figure out what to add 
where. And then we have exactly the element of frustration that harms the 
product.

Simon