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

[Simon Hausmann]

On Thursday 9. April 2015 12.34.17 Marc Mutz wrote:
> On Thursday 09 April 2015 10:39:57 Simon Hausmann wrote:
> > 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.
> 
> So, by this line of reasoning, the list of #includes in a public header file
> must be a monotonically increasing function of the Qt version. Since we're
> keeping SC even across major versions these days, we'll thus slowly
> converge on including all of a Qt module's headers in each of its headers.
> So, why don't we shortcut the process and include <QtFoo> in each
> QtFoo-module's header _today_? :)
> 
> I'm exaggerating, of course. A bit, at least.

Right, you are exaggerating. And that's why I don't agree with your enhanced 
line of reasoning.

> I wonder: wouldn't it also harm the project if people who use Qt for a
> living, pay your salary by buying licenses and have to spend X amount of
> money on additional hardware just to make the nightly builds actually build
> in just one night started to look for alternatives?

Surely it would. However at the same time I strongly doubt that the proposed 
changes have a significant impact on the overall build times, especially 
compared to the much more expensive human developer time that is spent when 
encountering source incompatible changes and a reduction of daytime 
productivity is the result.


Simon