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.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
