[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Thiago Macieira]

On Sunday 18 January 2015 04:07:02 Kevin Kofler wrote:
> > - it was agreed upon in 2011
> 
> Fedora never agreed to the solution that was implemented. It clearly does
> not fulfill our requirements. Never did, never will.

Unanimity was not required. Only consensus and that was achieved. The requests 
for renaming were argued and heard (I argued for them myself, I even prepared 
patches and had the solution in progress) but in the end the consensus was 
another way. Now everyone, including me, has to abide by that decision, unless 
there's new relevant information that didn't exist then. You haven't presented 
any new information.

Therefore the solution stands. Fedora can choose to abide by the consensus 
that was formed or do whatever it chooses anyway. If you choose the latter, 
don't expect us to take your arguments into account in the future (we promise 
to listen, at least).

> Keeping tool invocation compatibility for a new major version of a library,
> which will definitely not be 100% source-compatible anyway (at the very
> least, deprecated functions will be dropped), strikes me as a "feature" of
> very limited usefulness.

Well, evidence proves you wrong here.

Qt Creator compiled for a LONG time with both Qt 4 and 5. Does it still? I'm 
not sure. It used both the "very limited usefulness" feature of Qt 5 being 
almost source compatible with Qt 4 as well as qmake's "very limited 
usefulness" solution too.

If Qt Creator, complex as it is, can do it, simpler applications can too.

Another example is Subsurface, the project I work on in my spare time (which 
isn't a lot). Only now are we considering dropping Qt 4 support.

There were also quite a few people who reported very ease of porting to Qt 5. 
I remember even a few who ported "accidentally", when they ran the wrong 
qmake.

> Programs will likely need some amount of adaptation to Qt 6 anyway (they
> typically did for Qt 5) and so changing a hardcoded moc-qt5 (which they
> should already be using rather than moc at this point – if they're still
> using deprecated stuff, they'll need to get rid of that before porting to
> Qt 6, this also goes for the code anyway) to trying both moc-qt6 and moc-qt5
> is going to be the least of the developer's worries.

It's work they don't have to do -- death by a thousand paper cuts. Why should 
we make them change when it's within our grasp not to force that change? This 
was the argument that won the discussion over the not-renaming back in 
2011-2012 and it's still valid today. Another argument is reducing the barrier 
of entry into Qt 5. For the rest of the arguments, please refer to the 
archives.

Once again: I argued against it in 2011-2012, but you don't see me rebelling 
against that now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center