On Tue, 2016-12-13 at 19:45 +0100, Kevin Kofler wrote:
Przemek Klosowski wrote:
The reason why I'm asking is that I believe that in general FOSS
projects should fork as little as possible, and merge as much as
possible, to avoid duplication of effort. There are circumstances where
the fork is the only solution, of course, and I am asking what are the
circumstances in this case.
In this case, it looks like they forked because of the totally closed
development structure of the upstream project and its unwillingness to port
from Qt 3 to Qt 4. By now, we are in Qt 5 era, and the projects have
diverged so much that a merger is highly unlikely.
I haven't followed the fork -- I didn't even realize it existed until this thread
-- I stayed with upstream, even buying a license for a few years. While it'd be nice
to see it move along to a newer Qt, I've been very impressed with the feature
additions since it became closed and open again. I'm equally unimpressed with his
build processes; one glaring example is
http://www.qcad.org/bugtracker/index.php?do=details&task_id=1369. I started packaging
it for myself just to work around such issues.
So I'm curious, has the fork maintained any sort of feature parity? Did it adopt Qt 4
or 5? If not, I'd much prefer to see the upstream product make it back to Fedora. If
the fork does use a newer Qt but hasn't progressed much feature-wise then I don't
know what to think of the situation other than it sucks.